Au-delà du code applicatif : étendre le CI/CD à la configuration, au mobile et aux feature flags

Vous avez des pipelines CI/CD opérationnels pour votre code applicatif, vos migrations de base de données et votre provisionnement d'infrastructure. Les déploiements sont plus fluides, les rollbacks plus rapides, et votre équipe dort mieux la nuit. Mais il persiste un sentiment diffus qu'il manque encore quelque chose.

Le problème se manifeste par de petits signes. Un collègue doit modifier une chaîne de connexion à la base de données pour l'environnement de staging. La correction est triviale – il suffit de mettre à jour une valeur de configuration – mais elle nécessite un cycle de déploiement complet parce que la configuration est intégrée au code. Ou alors votre équipe mobile publie une nouvelle version, mais la revue de l'app store prend trois jours, et personne n'avait anticipé ce délai. Ou encore une fonctionnalité censée être déployée progressivement auprès des utilisateurs est soit complètement active, soit complètement désactivée, faute de mécanisme de contrôle sans redéploiement.

Ce ne sont pas des cas marginaux. Ce sont les points par lesquels la plupart des implémentations CI/CD commencent à montrer leurs failles. La bonne nouvelle, c'est qu'étendre votre pipeline pour gérer la configuration, les applications mobiles et les feature flags est simple une fois que vous savez quoi chercher.

La configuration comme voie de livraison séparée

La plupart des équipes commencent par stocker la configuration dans des variables d'environnement ou des fichiers de configuration qui accompagnent le code applicatif. Cela fonctionne jusqu'au jour où ce n'est plus le cas. Dès que vous devez modifier une valeur pour un environnement sans toucher aux autres, vous réalisez que la configuration et le code ont des cycles de vie différents.

Les changements de configuration ne devraient pas nécessiter de build. Ils ne devraient pas nécessiter l'exécution de toute la suite de tests. Ils ne devraient pas nécessiter un déploiement qui redémarre l'application. Une chaîne de connexion à une base de données, une clé API ou la valeur d'un feature toggle n'est pas du code. Les traiter comme du code ajoute une friction inutile.

La solution consiste à séparer la configuration du code et à lui donner son propre pipeline. Ce pipeline est plus simple que celui du code applicatif :

1. Une modification d'une valeur de configuration est commitée dans un dépôt
2. La modification passe par le même processus de revue que les changements de code
3. Une fois approuvée, la configuration est appliquée à l'environnement cible
4. L'application récupère la nouvelle valeur sans redémarrage

La différence clé est que le pipeline de configuration ignore les étapes de build et de test. Il n'y a rien à compiler ni à tester unitairement. Ce qui compte, c'est que la configuration atteigne le bon serveur et que l'application puisse la recharger dynamiquement.

Cette approche facilite également l'audit. Chaque changement de configuration est tracé dans le gestionnaire de versions, relu par un pair, et appliqué via un pipeline. Fini les connexions SSH à un serveur pour modifier une valeur en espérant que personne ne le remarque.

Les pipelines mobiles ont des contraintes différentes

Les applications mobiles ressemblent à n'importe quel autre projet logiciel jusqu'au moment où vous essayez de les déployer. Le processus de build produit un fichier d'installation qui doit être signé numériquement. La distribution passe par des app stores qui ont leurs propres processus de revue. Et une fois qu'une version est entre les mains des utilisateurs, vous ne pouvez pas les forcer à la mettre à jour.

Ces contraintes changent la conception du pipeline. Les étapes de build et de tests unitaires fonctionnent de la même manière que pour les applications backend. Mais l'étape de déploiement nécessite deux chemins distincts :

Le premier chemin est destiné à la distribution interne. Avant d'envoyer un build à l'app store, votre équipe doit le tester sur des appareils réels. Des plateformes comme Firebase App Distribution pour Android et TestFlight pour iOS permettent de distribuer des builds aux équipes QA et aux bêta-testeurs sans passer par le processus de revue de l'app store. Votre pipeline devrait automatiquement télécharger les builds vers ces plateformes dès qu'une nouvelle version est prête pour les tests.

Le second chemin est destiné à la mise en production. C'est là que le pipeline soumet le build signé au Google Play Store ou à l'Apple App Store. Le pipeline ne peut pas contrôler la durée de la revue, mais il peut en suivre le statut. Lorsque la revue est approuvée, le pipeline peut déclencher la publication effective auprès des utilisateurs.

Les barrières de risque pour les pipelines mobiles doivent inclure des vérifications spécifiques au mobile. Les dates d'expiration des certificats, la validité des clés de signature et l'incrémentation des numéros de version doivent être vérifiées automatiquement. Un build avec un certificat expiré sera rejeté par l'app store, et le découvrir après avoir attendu la revue est douloureux.

Les feature flags permettent des déploiements progressifs

Les feature flags sont un mécanisme qui permet d'activer ou de désactiver des fonctionnalités sans déployer de nouveau code. Ils résolvent un problème courant : une fonctionnalité est terminée, mais vous n'êtes pas sûr qu'elle soit prête pour tous les utilisateurs. Peut-être a-t-elle besoin de plus de tests. Peut-être voulez-vous la déployer d'abord auprès d'un petit pourcentage d'utilisateurs. Peut-être voulez-vous la possibilité de la désactiver rapidement si quelque chose tourne mal.

Sans feature flags, vos options sont limitées. Vous pouvez retarder le déploiement jusqu'à être confiant, ce qui ralentit la livraison. Ou vous pouvez déployer et espérer que tout se passe bien, ce qui augmente le risque. Les feature flags offrent une troisième option : déployer la fonctionnalité dans un état désactivé, puis l'activer progressivement.

Ajouter des feature flags à votre pipeline nécessite deux changements :

Premièrement, le pipeline doit vérifier que le code fonctionne correctement dans les deux états. Lorsqu'une fonctionnalité est encapsulée dans un flag, les tests doivent s'exécuter avec le flag activé et désactivé. Cela permet de détecter les cas où la logique du feature flag elle-même contient des bugs, ou où l'état désactivé casse des fonctionnalités existantes.

Deuxièmement, le pipeline devrait vous aider à nettoyer les flags qui ne sont plus nécessaires. Les feature flags qui restent dans le codebase indéfiniment deviennent une dette technique. Ils ajoutent de la complexité, rendent le code plus difficile à lire et augmentent le risque de bugs. Une bonne pratique consiste à ajouter une étape dans le pipeline qui vérifie les flags ayant été déployés à 100 % des utilisateurs pendant une période définie, puis crée automatiquement une tâche pour les supprimer.

Exemple de configuration de feature flag

Par exemple, un fichier de configuration de feature flag pourrait ressembler à ceci :

{
  "new_checkout": {
    "enabled": true,
    "rollout_percentage": 10,
    "description": "Déploiement progressif du nouveau flux de paiement"
  },
  "dark_mode": {
    "enabled": false,
    "rollout_percentage": 0,
    "description": "Activation du mode sombre pour tous les utilisateurs"
  },
  "search_autocomplete": {
    "enabled": true,
    "rollout_percentage": 100,
    "description": "Autocomplétion dans la barre de recherche, déployée à 100 %"
  }
}

L'application lit ce fichier au démarrage et vérifie périodiquement les mises à jour. Modifier rollout_percentage de 10 à 50 ne nécessite ni build ni déploiement — l'application récupère la nouvelle valeur dynamiquement.

Schéma des pipelines

Le diagramme ci-dessous montre comment le pipeline principal se ramifie en trois chemins distincts, chacun avec son propre cycle de vie.

Liste de contrôle pratique pour étendre votre pipeline

Avant de commencer à implémenter ces changements, parcourez cette liste de contrôle pour identifier ce qui nécessite votre attention :

• Pouvez-vous modifier une valeur de configuration pour un environnement sans redéployer l'application ?
• Chaque changement de configuration est-il tracé dans le gestionnaire de versions et relu avant d'être appliqué ?
• Votre pipeline mobile distribue-t-il automatiquement les builds aux testeurs internes ?
• Votre pipeline mobile vérifie-t-il l'expiration des certificats et la validité des clés de signature ?
• Les feature flags sont-ils testés à la fois dans l'état activé et désactivé ?
• Avez-vous un processus pour supprimer les feature flags qui ne sont plus nécessaires ?

Si vous avez répondu non à l'une de ces questions, vous avez une prochaine étape claire.

Ce qu'il faut retenir

Le CI/CD n'est pas complet lorsque votre code applicatif se déploie sans accroc. Il est complet lorsque chaque changement qui affecte le comportement de votre logiciel – qu'il s'agisse de code, de configuration ou d'un feature toggle – passe par un processus contrôlé, automatisé et auditable. Les pipelines de configuration suppriment la friction des changements spécifiques à un environnement. Les pipelines mobiles gèrent les contraintes uniques de la distribution via les app stores. Les feature flags vous donnent la capacité de contrôler les risques sans ralentir la livraison.

Commencez par le domaine qui cause le plus de douleur dans votre équipe aujourd'hui. Pour la plupart des équipes, c'est la gestion de la configuration. Une fois que cela fonctionne, passez au mobile ou aux feature flags selon ce que votre équipe livre. L'objectif n'est pas de construire le pipeline parfait dès le premier jour. L'objectif est de s'assurer que rien ne passe entre les mailles du filet.