La CI/CD n’est pas une priorité !

Dans beaucoup d’équipes et projets que j’ai accompagnés dans leur transformation DevOps, le réflexe et l’initiative de départ étaient de « mettre en place une CI/CD ». Apparement, c’est un gage de sérieux, d’industrialisation et de modernité. Mais trop souvent, cette mise en place était prématurée, mal comprise, ou incomplète.

Avant de déployer une CI/CD, il faut savoir ce que c’est réellement, et surtout ce que cela implique. Car une CI/CD mal conçue peut donner une fausse impression de qualité… tout en laissant passer des bugs, des failles ou des régressions.

La CI/CD, ce n’est pas juste un script qui tourne

Très souvent, les équipes ont des pipelines avec un lancement manuel ou périodique non orchestrés ni pilotés — Combien de pipelines aujourd’hui voient les tests désactivés ou la qualimétrie suspendue ?

Or, un vrai pipeline CI/CD n’est pas un ensemble d’étapes automatisées qu’on lance manuellement. Ce n’est pas non plus un job périodique qui tourne la nuit ou toutes les heures.

C’est un processus qui se déclenche automatiquement à chaque modification de code, sensible à la qualité du livrable, et capable de stopper la chaîne en cas d’anomalie.

On ne peut parler de CI/CD que si :

• Le déclenchement et les étapes sont entièrement automatisés (push, tag, PR, merge…) ;

• Les erreurs bloquent la chaîne (tests, qualité, sécurité, conformité…) ;

• Le déploiement est défini selon une stratégie appropriée (Blue/Green, Canary, Rolling Update, …)

Un pipeline qui continue malgré des tests qui échouent ou des vulnérabilités connues n’est pas une chaîne CI/CD. L’automatisation n’est pas qu’un gain de temps : c’est un garde-fou.

💡Il n'est pas nécessaire d'avoir à la fois la CI et la CD pour considérer le travail comme sérieux. Il vaut mieux maîtriser l'une des deux avec un processus fiable et contrôlé, puis construire le reste progressivement.

Pourquoi ne pas commencer par la CI/CD ?

Si vous lancez une CI/CD sans avoir sécurisé :

• L’architecture logicielle,

• Le système de persistance,

• La qualité et la sécurité des livrables,

• Les stratégies appropriées de livraison et de rollback,

… vous risquez d’accélérer la mise en production des erreurs au lieu de la valeur.

La mise en place d’une CI/CD suppose que les questions suivantes ont déjà été résolues :

• Comment tester ? (unitaires, intégration, end-to-end, …)

• Comment contrôler la qualité ? (lint, coverage, complexité, …)

• Comment analyser la sécurité ? (SAST, dépendances, droits d’accès, …)

• Quelle stratégie de déploiement adopter ? (blue/green, rolling, feature flag)

Sans avoir des réponses claires à ces questions et les outils appropriés sur place, c’est déployer tout simplement un processus flou sans aucune valeur ajoutée. Surtout que toute mesure de temps de livraison ou de déploiement sera erronée, car le déploiement n’est pas un processus fiable.

⚠️ Une CI/CD qui casse la prod ou qui n’est pas en mesure d’effectuer un retour-arrière est une CI/CD incomplète.

Ce qu’on oublie souvent : Le système de persistance

Le vrai danger de l’automatisation sans contrôle préalable est lié directement au système de persistance, souvent irréversible une fois modifié.

👉 Ci-après quelques composants auxquels il faut penser AVANT de mettre en œuvre la CI/CD (liste non exhaustive) :

Ce qu’on rencontre régulièrement : Un seul pipeline pour tout gérer !

Un seul pipeline pour déployer les composants applicatifs et d’infrastructure est une très mauvaise pratique. Il est crucial de distinguer deux types de pipelines aux objectifs et temporalités différentes :

Les changements applicatifs sont généralement plus fréquents que les changements d'infrastructure. Il est donc recommandé de maintenir des pipelines séparés pour éviter des redéploiements inutiles de l'infrastructure lors de modifications applicatives.

Il est également important de noter que certaines stratégies de déploiement ne s'appliquent pas à l'infrastructure ou ne sont pas appropriées (Recreate, Feature Toggle, A/B Testing, etc.).

Pipeline d’infrastructure : ordre, code et précaution

Le pipeline d'infrastructure repose sur trois principes fondamentaux :

1. Infrastructure as Code (IaC)
   Utilisez des outils comme Terraform ou Pulumi pour décrire, versionner et auditer l'infrastructure.

2. Configuration as Code (CaC)
   Employez des outils tels qu'Ansible, Helm ou Kustomize pour gérer les paramètres d'environnement, les secrets, les chemins, les limites de mémoire, etc.

3. Déploiement séquencé et autonome des composants
   Déployez les composants dans un ordre logique pour assurer la stabilité et la cohérence du système. Ce déploiement doit être modulaire, où chaque composant est autonome et possède sa propre stratégie (par exemple, un tfState par composant et non par déploiement complet).

Le pipeline d’infrastructure : un processus orchestré, pas forcément continu

Contrairement au pipeline applicatif, qui s’exécute automatiquement à chaque modification de code, le pipeline d’infrastructure peut (et doit souvent) être soumis à une validation manuelle.

Pourquoi ?

• Les changements d’infrastructure peuvent avoir un impact large (pannes, indisponibilité, …).

• Ils doivent respecter des fenêtres de maintenance, des procédures de contrôle, ou une stratégie de montée en charge.

• Certaines opérations (provisionnement de base de données, modification réseau, montée de version d’un broker Kafka) nécessitent une validation humaine.

Enfin, le rythme de déclenchement dépend de l’environnement :

Automatiser ne signifie pas abandonner le discernement. En matière d’infrastructure, l’automatisation encadre, documente, trace… mais ne remplace pas la responsabilité. Le pipeline d’infrastructure est donc une brique stratégique du SI qui doit rester sous contrôle.

Déploiement piloté par stratégie

Chaque fonctionnalité ou composant peut nécessiter une stratégie de déploiement spécifique. Un fichier JSON ou YAML permet de définir cela dynamiquement :

{
  "feature": "recommendationV3",
  "strategy": "blue-green",
  "rollbackOnError": true,
  "preDeployTests": ["load", "regression"],
  "persistenceSafetyChecks": {
    "dbMigrationIdempotent": true,
    "messageSchemaBackwardCompatible": true,
    "configFallback": true
  }
}

Ce type de configuration permet d'adapter le déploiement aux spécificités de chaque projet au niveau de chaque commit, tout en assurant des garde-fous pour préserver la stabilité du système.

La CI/CD doit être en mesure de choisir une stratégie de déploiement adaptée à la fonctionnalité ou au contexte en s’appuyant sur un répertoire dédié à la configuration.

Un aperçu des différentes stratégies de déploiement :

Chaque stratégie de déploiement présente des avantages et des limites. Le choix de l’approche la plus pertinente dépend des besoins spécifiques du projet, de la complexité des évolutions à livrer, ainsi que du niveau de tolérance aux interruptions de service.

Il revient à l’équipe d’évaluer l’ensemble des critères (impact utilisateur, coût, complexité, …) afin d’adopter la méthode de déploiement la mieux adaptée à leur contexte technique, métier et organisationnel.

Conclusion

Mettre en place une CI/CD, ce n’est pas simplement cocher une case. C’est établir un cadre d’exécution fiable, traçable et sécurisé, garantissant la qualité des livraisons et assurant la continuité du service.

La CI/CD doit être une démarche progressive, adaptée à chaque projet. Cependant, pour maximiser son efficacité, elle doit s’appuyer sur des outils communs, des bonnes pratiques et des standards organisationnels bien définis. En respectant ces standards, on assure non seulement la cohérence et la stabilité du processus, mais aussi la sécurité et la conformité de l’ensemble des livrables à long terme.

---

Merci pour votre lecture !
Si vous avez apprécié cet article, n’hésitez pas à me suivre sur LinkedIn pour découvrir mes prochaines publications.
Une remarque ou une suggestion ? Laissez un commentaire ci-dessous — j’y répondrai avec plaisir 👌