CI/CD Standardisé : Même Pipeline, Encore Trop de Travail Manuel

Vous avez un pipeline. Chaque équipe l'utilise. Le code entre, les builds s'exécutent, les tests tournent, les déploiements ont lieu. Mais malgré tout, faire passer un changement en production reste une véritable corvée. Le pipeline est là, mais le processus est lent. Quelqu'un doit approuver chaque modification. La QA doit tester manuellement l'environnement de staging. Le déploiement en production nécessite qu'une personne se connecte et exécute des commandes ou clique sur des boutons à un moment précis.

C'est le niveau 2 du modèle de maturité CI/CD : Standardisé. Votre organisation a dépassé le chaos où chacun faisait à sa sauce. Il existe un pipeline partagé. Il y a de la cohérence. Mais il reste encore beaucoup de travail manuel qui ralentit la livraison.

À quoi ressemble le niveau Standardisé

À ce niveau, le pipeline n'est plus un mystère. Chaque équipe suit le même flux : commit, build, test, déploiement en staging, et finalement en production. Personne ne construit depuis son poste avec des outils ou des configurations différents. L'environnement de build est cohérent. Les étapes de test sont définies. Le processus de déploiement est documenté.

Mais voilà le problème : le pipeline s'arrête au staging. Ou il nécessite une approbation manuelle pour continuer. Ou il faut que quelqu'un exécute un script. L'automatisation existe, mais elle est incomplète. Les humains sont encore dans la boucle pour les étapes critiques.

Le diagramme ci-dessous montre le flux typique du pipeline à ce niveau, avec les étapes manuelles surlignées en rouge.

Le goulot d'étranglement des approbations

L'un des plus gros ralentissements à ce niveau est le processus d'approbation. Chaque changement qui veut atteindre la production nécessite le feu vert d'une personne ou d'un groupe spécifique. Cette approbation peut arriver par email, un message instantané, ou une réunion rapide. Mais elle arrive rarement rapidement.

La personne qui doit approuver est peut-être dans une autre réunion. Elle peut être en congé. Elle peut être occupée par un incident. Ou elle peut simplement ne pas vouloir être celle qui assume la responsabilité si quelque chose tourne mal. Alors le changement reste dans le pipeline, en attente. Les heures se transforment en jours. Le pipeline lui-même est prêt, mais le processus ne l'est pas.

Ce n'est pas un problème d'outil. Vous pouvez avoir la meilleure plateforme CI/CD du monde, mais si chaque déploiement nécessite qu'un humain dise « oui », vous êtes toujours limité par la disponibilité humaine.

Les tests manuels existent toujours

Un autre signe du niveau Standardisé est que tous les tests ne sont pas automatisés. Les tests unitaires et d'intégration peuvent s'exécuter dans le pipeline. Mais pour certains scénarios, la QA doit encore se connecter à l'environnement de staging, exécuter des cas de test manuellement et rédiger un rapport.

Cela crée un cycle. Un développeur pousse une modification. Les tests automatisés passent. Mais la QA doit vérifier manuellement la fonctionnalité. S'ils trouvent un problème, la modification retourne au développeur. Le développeur corrige, repousse, et la QA répète les tests manuels. Chaque itération prend du temps.

Le problème n'est pas que les tests manuels soient inutiles. Certaines choses sont difficiles à automatiser, surtout les flux utilisateur complexes ou les cas limites. Le problème est que les tests manuels sont traités comme une porte qui doit être franchie avant chaque déploiement, même pour les petits changements. Cela ralentit tout le processus de livraison.

Le déploiement reste une étape manuelle

Même avec un pipeline standardisé, le déploiement en production reste souvent une action manuelle. Le pipeline peut builder et tester automatiquement, mais quand il s'agit de pousser en production, quelqu'un doit exécuter une commande ou cliquer sur un bouton dans un tableau de bord.

Certaines organisations suivent encore un calendrier de release. Ils déploient une fois par semaine ou une fois par mois, même si le pipeline est prêt à déployer à tout moment. La raison est souvent la peur. Sans automatisation complète et confiance dans le processus, les équipes préfèrent regrouper les changements et déployer pendant une fenêtre planifiée où tout le monde est disponible pour gérer les problèmes.

C'est compréhensible, mais cela va à l'encontre du but d'avoir un pipeline. Le pipeline vous donne la capacité de déployer rapidement, mais le processus vous empêche d'utiliser cette capacité.

La documentation existe, mais est-elle utile ?

Au niveau Standardisé, la documentation commence à apparaître. Il peut y avoir une page wiki expliquant comment déployer, comment faire un rollback, ou comment gérer les erreurs courantes. Mais cette documentation est souvent obsolète. Ou incomplète. Ou les gens préfèrent simplement demander à un collègue plutôt que de la lire.

Le problème est que la documentation est traitée comme un artefact séparé, pas comme une partie du processus. Elle est écrite une fois puis oubliée. Quand quelque chose change, la documentation n'est pas mise à jour. Quand une nouvelle personne rejoint l'équipe, elle doit apprendre des autres plutôt qu'à partir de la documentation.

Le bon côté : la cohérence

Malgré tous ces problèmes, le niveau Standardisé est une amélioration significative par rapport au niveau précédent. Le plus grand avantage est la cohérence. Parce que chaque équipe utilise le même pipeline, les résultats de build et de test sont fiables. Si un build échoue, il échoue pour tout le monde de la même manière. Il n'y a plus de « ça marche sur ma machine » parce que chaque changement passe par le même chemin.

Cette cohérence facilite le débogage. Quand quelque chose tourne mal, les équipes savent où chercher. Les logs du pipeline sont standardisés. Les configurations d'environnement sont les mêmes. Les étapes de test sont prévisibles. Cela réduit le temps passé à résoudre les problèmes et augmente la confiance dans le processus.

Le mauvais côté : toujours lent

Mais l'inconvénient est clair : trop de travail manuel ralentit tout. Chaque étape manuelle est un point d'attente. Approbation, tests manuels, déploiement manuel, documentation obsolète — tout cela ajoute du temps entre l'écriture du code et la livraison de valeur aux utilisateurs.

Les équipes à ce niveau ont souvent l'impression d'avoir progressé. Elles ont un pipeline. Elles ont de la cohérence. Mais elles sont aussi frustrées car la livraison n'est toujours pas rapide. Elles savent qu'elles peuvent faire mieux, mais elles ne savent pas comment y parvenir.

Une checklist pratique pour le niveau 2

Si vous êtes à ce niveau, voici quelques points à vérifier :

• Chaque étape d'approbation est-elle nécessaire, ou certaines peuvent-elles être automatisées en fonction des résultats des tests ?
• Quels tests manuels peuvent être automatisés et ajoutés au pipeline ?
• Le déploiement en production peut-il être déclenché automatiquement si tous les tests passent ?
• La documentation est-elle mise à jour dans le cadre du processus de déploiement, et non comme une tâche séparée ?
• Les équipes attendent-elles quelqu'un d'autre avant de pouvoir déployer ?

Ces questions aident à identifier les plus gros goulots d'étranglement. L'objectif n'est pas d'éliminer tout le travail manuel d'un coup. Il s'agit de trouver les étapes qui causent le plus de retard et de les réduire une par une.

La prochaine étape : le libre-service

Le niveau Standardisé est un pont. Votre organisation a les bonnes fondations. Le pipeline existe. Le processus est cohérent. Mais vous ne l'utilisez pas à son plein potentiel. La prochaine étape est de réduire le travail manuel jusqu'à ce que les équipes puissent gérer leurs propres déploiements sans attendre les autres.

C'est le niveau libre-service. Les équipes peuvent déployer quand elles en ont besoin, avec des vérifications automatisées remplaçant les portes manuelles. L'approbation devient une exception, pas la règle. Les tests sont automatisés autant que possible. La documentation est générée à partir du processus, et non rédigée séparément.

Mais avant d'y arriver, vous devez reconnaître qu'avoir un pipeline n'est pas la même chose qu'avoir une livraison rapide. La standardisation vous donne de la cohérence. La prochaine étape vous donne de la vitesse.

À retenir

Un pipeline standardisé est un bon début, mais ce n'est pas la ligne d'arrivée. Si votre équipe a un pipeline partagé mais lutte encore avec des approbations lentes, des tests manuels et des déploiements planifiés, vous êtes au niveau 2. Le pipeline est prêt. Le processus ne l'est pas. Le travail maintenant est de supprimer les étapes manuelles qui ralentissent votre livraison.