Aller au contenu principal

Foire Aux Questions Fréquentes (FAQ)

Retrouvez ici les réponses exhaustives aux questions les plus fréquemment posées par les architectes logiciels, RSSI et développeurs mobiles exploitant TkushPatch.

1. Architecture et Principes Généraux​

Q1. Qu'est-ce que TkushPatch exactement ?​

TkushPatch est une plateforme souveraine et auto-hébergeable de mise à jour de code à distance (Over-The-Air Code Push) pour les applications Flutter. Elle permet de déployer des correctifs de bugs et des évolutions logiques en quelques secondes directement sur les terminaux des utilisateurs, sans nécessiter de nouvelle soumission aux stores.

Q2. En quoi TkushPatch diffère-t-il de Shorebird Cloud ?​

TkushPatch offre une souveraineté numérique totale : l'intégralité du code backend (ota-server), de la console d'administration (ota-web-console), du moteur de signature moteur cryptographique et de la base de données est déployée sur vos propres serveurs ou cloud privé. Aucune donnée télémétrique ni binaire ne transite par des serveurs tiers américains. De plus, TkushPatch intègre nativement la gouvernance 4-Yeux bancaire, le filtrage géographique par pays et l'authentification 2FA renforcée.

Q3. Quels langages et technologies composent TkushPatch ?​

  • Data Plane & Updater Client : Moteur natif écrit en Rust (updater/library) pour des performances et une sécurité mémoire maximales.
  • Backend API (Control Plane) : Serveur TkushPatch 3 (Java 21) avec architecture hexagonale, base de données et moteur cryptographique.
  • Console Web : Next.js 15 (React 19, TypeScript, Tailwind CSS).
  • CLI Développeur : Outil compilé en Dart (tk-ota-push).
  • SDK Mobile : Package Flutter / Dart (tk_ota_push).

Q4. TkushPatch fonctionne-t-il avec toutes les versions de Flutter ?​

TkushPatch supporte les versions stables de Flutter 3.10.x jusqu'aux versions les plus récentes de Flutter 3.x, tant pour Android que pour iOS.

Q5. L'application mobile fonctionne-t-elle si le serveur TkushPatch est injoignable ?​

Oui, sans aucune interruption. Si le smartphone est hors-ligne ou si le serveur est temporairement inaccessible, le SDK ignore la mise à jour et continue d'exécuter la dernière version valide présente en cache local ou le binaire de base du Store.

2. Différentiels Binaires et Algorithmes​

Q6. Comment TkushPatch parvient-il à générer des patchs de quelques dizaines de kilo-octets ?​

TkushPatch n'envoie jamais l'intégralité du fichier binaire compilé (binaire d'application). Il utilise l'algorithme différentiel différentiel binaire combiné à la compression ultra-efficace compression optimisée. Le serveur calcule la différence mathématique stricte entre le binaire d'origine et le nouveau binaire, produisant un micro-diff représentant généralement 1 % à 3 % de la taille totale du binaire.

Q7. Quelles modifications de code peuvent être incluses dans un patch OTA ?​

Tout le code source Dart, les widgets Flutter, la logique métier, les calculs, les chaînes de traduction, les appels d'API et les assets statiques (images, polices).

Q8. Quelles modifications NE PEUVENT PAS être déployées par patch OTA ?​

Les modifications apportées au code natif sous-jacent :

  • Code C++ / Java / Kotlin (fichiers sous android/ ou bibliothèques tierces avec code natif additionnel).
  • Code Objective-C / Swift (fichiers sous ios/).
  • Nouvelles permissions système dans le AndroidManifest.xml ou Info.plist. Toute modification native exige obligatoirement une nouvelle release de base soumise au Store.

Q9. Que se passe-t-il si un développeur tente d'envoyer un patch contenant du code natif modifié ?​

Le CLI et la console d'approbation inspectent automatiquement le hash du pont natif. Si une anomalie est détectée, le patch est bloqué par le garde-fou patch.native_bridge_ok == false et refusé avant signature.

3. Sécurité, Cryptographie et Règle des 4 Yeux​

Q10. Comment est garantie l'authenticité d'un patch téléchargé ?​

Chaque patch est signé asymétriquement par une clé privée signature numérique/4096 conservée dans moteur cryptographique. Lors de la compilation initiale de l'application pour le Store, la clé publique correspondante est incrustée de manière permanente dans le binaire. Le moteur Rust vérifie la signature signature numérique avant d'exécuter le moindre octet de code.

Q11. Qu'est-ce que la règle des 4 Yeux (Maker-Checker) ?​

C'est une exigence réglementaire bancaire interdisant à un collaborateur unique de déployer un patch en production :

  • Le développeur mobile (Maker) compile et téléverse le patch, qui se retrouve en quarantaine STAGED.
  • L'officier de sécurité (Checker) inspecte le patch sur la console /approvals et ordonne sa Signature cryptographique. L'auto-approbation est formellement bloquée dès que l'organisation compte plus d'un membre.

Q12. Comment fonctionne le mode développeur solo ?​

Lorsqu'une organisation ne compte qu'un seul utilisateur (totalMembers == 1), l'auto-approbation est autorisée par dérogation afin d'éviter tout blocage opérationnel. L'action est scellée dans l'audit sous le statut PATCH_APPROVED_SOLO_OVERRIDE. Dès qu'un second membre rejoint l'équipe, la règle des 4 Yeux stricte s'active automatiquement.

Q13. Les codes de validation 2FA OTP sont-ils stockés en clair dans la base ?​

Non. Les codes bruts à 6 chiffres sont générés par un générateur d'aléa cryptographique (SecureRandom), salés avec un secret d'organisation et hachés en SHA-256. Seul le hash est persisté en base de données centrale.

Q14. Que se passe-t-il en cas de corruption d'un patch téléchargé sur le mobile ?​

Le moteur natif Rust recalcule le hash SHA-256 du fichier après téléchargement. Si le hash ne correspond pas au digest officiel ou si la signature RSA est invalide, le patch est immédiatement purgé du stockage flash du terminal et l'application conserve sa version précédente.

4. Conformité aux Magasins (Google Play et Apple App Store)​

Q15. L'usage d'un moteur de Code Push est-il autorisé par Google Play ?​

Oui. Les règles de Google Play (Developer Program Policy) autorisent la mise à jour dynamique de code interprété ou compilé par une machine virtuelle (comme le runtime Flutter/Dart) tant que les modifications n'altèrent pas la finalité première de l'application déclarée sur la fiche Store.

Q16. Qu'en est-il des directives de l'Apple App Store (Section 3.3.2) ?​

Les directives pour les développeurs Apple (Apple Developer Program License Agreement, Section 3.3.2) autorisent expressément le code push de scripts et de code interprété dans un framework cross-platform, à condition que le code n'introduise pas de fonctionnalités contraires aux règles de l'App Store et préserve la sécurité de l'écosystème iOS.

Q17. Comment empêcher les patchs OTA d'interférer avec le processus de revue Apple ou Google ?​

TkushPatch propose l'option Bouclier de Revue Store (IN_STORE_REVIEW). Pendant la phase d'évaluation par les équipes d'Apple ou Google, le serveur désactive temporairement la distribution des patchs pour la version soumise, garantissant que les testeurs des stores examinent le binaire exact sans interférence OTA.

Q18. Pourquoi les numéros de version de patch sont-ils distincts du numéro de version Store ?​

La version Store (ex. 2.4.1+45) identifie le binaire natif compilé et validé par les magasins. Les patchs OTA (Patch #1, Patch #2) sont des correctifs incrémentaux appliqués par-dessus cette version de base sans incrémenter le numéro de build Store.

5. Canaux, Déploiement Canary et Politiques de Mise à Jour​

Q19. Qu'est-ce que le Canary Rollout progressif ?​

C'est une technique de déploiement permettant de diffuser un patch d'abord à un faible pourcentage d'utilisateurs (ex. 5 %, puis 25 %, 50 % et 100 %). Cela permet de mesurer la stabilité en conditions réelles avant la généralisation.

Q20. Comment fonctionne le ciblage géographique par pays ?​

La console permet de restreindre la diffusion d'un patch à un ensemble de codes pays ISO (ex. Cameroun CM, Côte d'Ivoire CI, Sénégal SN). Le serveur analyse l'adresse IP d'origine ou l'indicatif réseau de la carte SIM transmis par le SDK pour autoriser ou refuser le patch.

Q21. Quelle est la différence entre la politique "Wi-Fi Obligatoire" et "Mise à Jour Forcée" ?​

  • Wi-Fi Obligatoire : Le SDK attend que le smartphone soit connecté à un réseau Wi-Fi non mesuré pour télécharger le patch, évitant de consommer le forfait data 3G/4G/5G de l'utilisateur.
  • Mise à Jour Forcée : En cas de faille de sécurité critique, le SDK affiche un écran bloquant interdisant l'utilisation de l'application tant que le correctif n'a pas été appliqué et redémarré.

Q22. Qu'est-ce que la promotion inter-canaux Zéro-Recompilation ?​

Lorsqu'un patch a été validé sur le canal staging, vous pouvez le promouvoir sur le canal stable en un clic. Le serveur réutilise exactement le même artefact binaire .vmcode bit-à-bit, garantissant que le code déployé en production est mathématiquement identique à celui testé par l'équipe QA.

6. Exploitation, Résilience et Diagnostic​

Q23. Qu'est-ce que le Kill-Switch d'urgence ?​

Sur la page /rollout, le bouton Kill-Switch permet à l'ingénieur SRE de révoquer un patch en production en 1 clic. Dès leur prochaine requête, les applications connectées reçoivent l'ordre d'effacer le patch défectueux et de repasser instantanément sur la version de base du Store.

Q24. Comment l'application se comporte-t-elle si un patch provoque un crash au démarrage ?​

Le moteur natif Rust de TkushPatch intègre un garde-fou à 2 crashs consécutifs. Si l'application plante deux fois de suite au démarrage avec un patch actif, le moteur déclare le patch instable, l'efface automatiquement du disque et redémarre sur le binaire Store d'origine propre.

Q25. Comment désobfusquer les rapports de crashs en production ?​

Lors de chaque build de patch, le CLI archive les symboles Dart dans un fichier .symbols. Sur la console web (/symbols), vous pouvez coller une trace de pile obfusquée (#00 abs 0000007...) : le serveur la traduit instantanément en code source lisible avec les fichiers et numéros de lignes précis.

Q26. Combien de temps les anciens patchs sont-ils conservés sur le serveur ?​

Les métadonnées et signatures d'audit sont conservées de manière permanente pour les obligations légales. En revanche, les anciens différentiels .vmcode inactifs depuis plus de 90 jours peuvent être supprimés en un clic via la commande de Purge Day-2 sur l'écran /health.