CI/CD (Intégration Continue / Livraison Continue)

L'Intégration Continue signifie que chaque développeur soumet fréquemment du code à la branche principale partagée (idéalement plusieurs fois par jour) plutôt que de travailler sur des branches à longue durée de vie. Chaque soumission déclenche un pipeline automatisé qui : compile le code, exécute la suite complète de tests unitaires et d'intégration, effectue une analyse statique et du linting, construit un artefact déployable et signale le succès ou l'échec en quelques minutes. La règle culturelle critique du CI : les builds cassés sont la plus haute priorité de l'équipe à corriger — une branche principale défaillante bloque tout le monde et signale immédiatement la capacité de l'équipe à déployer. Le CI prévient l'« enfer de l'intégration » qui se produit lorsque les développeurs travaillent sur des branches isolées pendant des semaines et doivent ensuite fusionner toutes leurs modifications simultanément, provoquant des conflits et des bugs qui prennent des jours à démêler. Le Product Ops soutient le CI en s'assurant que les spécifications produit incluent des critères clairs et testables que les ingénieurs peuvent traduire en tests automatisés.

Les deux impliquent la préparation automatisée des artefacts de publication après le succès du CI, mais diffèrent dans l'étape finale. La Livraison Continue signifie que le logiciel est toujours dans un état déployable — passant toutes les vérifications automatisées, packagé et prêt à être livré — mais qu'un humain prend la décision explicite de déployer en production. Un déploiement est une action en un clic effectuée lorsque l'entreprise est prête. Le Déploiement Continu va un cran plus loin : chaque commit qui passe le pipeline CI est automatiquement déployé en production sans intervention humaine. La plupart des entreprises SaaS utilisent la Livraison Continue (déploiement déclenché par l'humain) combinée à des feature flags pour un déploiement contrôlé. Le Déploiement Continu est adopté par les équipes disposant d'une infrastructure de test et de surveillance extrêmement mature. Le Product Ops influence la cadence des décisions de déploiement — alignant le calendrier de déploiement avec le calendrier de publication pour s'assurer que la préparation GTM accompagne les changements de production.

Un pipeline CI/CD de qualité production (implémenté dans GitHub Actions, CircleCI, GitLab CI ou Jenkins) comprend ces étapes : Déclenchement (sur chaque pull request et fusion vers la branche principale) ; Build (compilation du code source, résolution des dépendances, création d'image Docker) ; Tests Unitaires (tests rapides couvrant les fonctions et composants individuels, durée d'exécution cible < 5 minutes) ; Tests d'Intégration (tests des interactions entre les composants, certains services externes simulés, cible < 15 minutes) ; Tests de Bout en Bout (tests d'automatisation du navigateur des flux utilisateurs critiques contre un environnement de staging, cible < 30 minutes) ; Analyse de Sécurité (outils SAST scannant les dépendances vulnérables et les problèmes de sécurité au niveau du code) ; Construction et Push de l'Artefact (artefact prêt pour la production poussé vers le registre de conteneurs) ; Déploiement en Staging (déploiement automatique vers l'environnement de staging pour vérification QA humaine) ; et Déploiement en Production (déclenchement manuel ou entièrement automatisé, avec activation de feature flag comme contrôle de déploiement). Le Product Ops surveille les métriques de santé du pipeline (taux de succès des builds, tendances de durée du pipeline) comme indicateurs de vélocité d'ingénierie.