Diagramme de pipeline CI/CD : du commit à la production, étape par étape

Demandez un diagramme CI/CD et vous obtiendrez le plus souvent une rangée de boîtes : build, test, déploiement. Ce n'est pas faux, mais cela ne répond à presque aucune des questions qu'on se pose en le regardant. Qu'est-ce qui est déployé, exactement ? Qui peut pousser en production ? Où sont les validations ? Comment revenir en arrière, et qu'est-ce qui nous dit qu'il le faut ?

Ce guide montre comment dessiner un diagramme de pipeline CI/CD qui répond à ces questions, en prenant pour exemple une configuration courante : des pull requests à la GitHub, un registre de conteneurs et des déploiements GitOps vers Kubernetes avec Argo CD. Les règles valent tout autant pour d'autres outils.

Ce qu'un diagramme de pipeline doit montrer

• Déclencheurs. Ce qui lance chaque partie : une pull request, un merge sur main, un tag, une exécution planifiée.
• Étapes et leur ordre. Lint, tests, build, scan, déploiement, vérification.
• Artefacts. Ce qui circule d'une étape à l'autre, en général une image de conteneur. Montrez comment il est identifié : par un tag ou, mieux, par un digest.
• Environnements. Où l'artefact s'exécute, et dans quel ordre il y arrive.
• Points de contrôle. Validations manuelles, vérifications obligatoires et politiques qui bloquent un changement.
• Identifiants. Quel système peut modifier quel environnement.
• Boucle de rétroaction. Comment les signaux de la production arrêtent ou annulent une version défectueuse.

Une rangée d'étapes couvre les deux premiers points. Le reste, c'est là que se jouent les incidents et les audits.

L'exemple : GitOps vers Kubernetes

1. Un développeur ouvre une pull request dans le dépôt applicatif.
2. La CI s'exécute à chaque push : lint, tests unitaires, build de l'image, scan. Lors d'un merge sur main, elle pousse l'image vers le registre et enregistre son digest.
3. La CI commite ensuite le nouveau digest de l'image dans l'overlay de staging d'un dépôt de configuration distinct.
4. Argo CD, dans le cluster de staging, repère le commit, récupère la configuration et synchronise le cluster.
5. Pour promouvoir la version, quelqu'un ouvre une pull request qui copie la référence dans l'overlay de production. Une revue obligatoire sert de point de validation.
6. Après le merge, Argo CD synchronise la production, et Argo Rollouts, un contrôleur distinct dans le cluster, déploie la nouvelle version en canary : d'abord une petite part du trafic, puis la totalité.
7. Pendant le canary, Argo Rollouts lance une analyse sur les métriques Prometheus. Une analyse en échec interrompt le rollout et renvoie le trafic vers la version stable ; les alertes préviennent alors l'ingénieur d'astreinte.

Deux détails de ce diagramme passent facilement inaperçus et comptent beaucoup. La CI ne parle jamais à un cluster : elle se contente de pousser l'image vers le registre et de commiter dans Git. Et la production ne change qu'au travers d'un commit relu, ce qui est aussi la façon de revenir en arrière : faites un revert du commit, et Argo CD synchronise la version précédente.

Push ou pull : dessinez où se trouvent les identifiants

Dans un pipeline en mode push, la CI détient des identifiants pour le cluster et lance elle-même la commande de déploiement. Dans une configuration GitOps en mode pull, un agent placé dans chaque cluster, comme Argo CD ou Flux, récupère l'état souhaité depuis Git et l'applique : rien à l'extérieur du cluster n'a besoin d'y accéder en écriture.

Les deux approches sont valables, et le diagramme doit rendre le choix évident. En push, tracez un lien de la CI vers chaque cluster et étiquetez-le avec l'identifiant utilisé. En pull, montrez le dépôt de configuration qui alimente l'agent de chaque cluster, sans aucun lien de la CI vers un cluster. Les relecteurs voient alors d'un coup d'œil le rayon d'impact d'une fuite de secret de la CI.

Si la CI a besoin d'accéder au cloud, par exemple pour pousser des images, indiquez comment elle obtient cet accès. Sur un diagramme, des jetons de courte durée obtenus via OpenID Connect font bien meilleure figure qu'une clé longue durée stockée comme secret.

Règles pour un diagramme de pipeline lisible

Rendez l'artefact visible

Étiquetez le lien qui entre dans le registre avec l'artefact et la façon dont il est identifié : image shop-api, by digest. Un tag peut être déplacé ; un digest désigne toujours la même image. Si vous produisez aussi un SBOM ou une signature, placez-les à côté de l'image.

Dessinez les environnements comme des cadres

Chaque environnement est un cadre qui contient son agent de déploiement et son cluster. L'ordre des cadres montre le chemin de promotion, et tout ce qui saute un cadre se remarque immédiatement.

Donnez aux points de contrôle leur propre nœud

Une validation est une étape qui a un responsable, pas une étiquette sur une flèche. Dessinez-la comme un nœud entre les environnements et indiquez qui valide : approve: release manager ou 2 reviews required.

Bouclez la boucle

Un pipeline qui s'arrête à « déploiement » n'a aucune boucle de rétroaction. Dessinez ce qui surveille la production et ce que cela peut faire : arrêter un canary, alerter quelqu'un, déclencher un rollback.

Laissez le détail des jobs dans le fichier de CI

Douze jobs de test parallèles ont leur place dans la configuration de CI. Sur le diagramme, un seul nœud d'étape avec une étiquette courte (lint, test, build, scan) suffit.

Erreurs courantes

• Pas d'artefact. Des boîtes reliées par des flèches qui ne transportent rien de précis. Le lecteur ne peut pas savoir ce qui est promu.
• Des environnements comme étapes. « Déployer en staging » et « déployer en prod » sous forme de deux boîtes alignées masquent qu'il s'agit d'endroits différents, avec des droits différents.
• Pas de chemin de rollback. Si personne ne peut le montrer sur le diagramme, il n'a probablement jamais été testé.
• Chaque job comme un nœud. Le diagramme se transforme en log de CI.
• Des outils plutôt que des responsabilités. Une boîte qui porte un nom de produit en dit moins que build and scan image.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack DevOps, ajoutez des nœuds Dépôt pour le dépôt applicatif et le dépôt de configuration, ainsi qu'un Pipeline CI/CD pour la CI. Ajoutez un Registre du pack Docker.
3. Ajoutez un Cadre du pack Base pour chaque environnement, avec à l'intérieur un nœud Déploiement du pack DevOps pour Argo CD (et Argo Rollouts en production) et un Cluster Kubernetes du pack Cloud.
4. Ajoutez une forme Losange du pack Base pour le point de validation.
5. Ajoutez les nœuds Métriques et Alerte du pack DevOps, ainsi que des nœuds Personne du pack Modèle C4 pour le développeur et l'ingénieur d'astreinte.
6. Connectez les ports, étiquetez chaque lien avec ce qui y circule, et passez le lien de rétroaction en tirets.

L'exemple utilise 15 nœuds de diagramme, la limite de l'offre Free. Pour un pipeline avec l'observabilité intégrée, ouvrez /examples/cicd-observability ; pour le côté cluster, consultez comment dessiner un diagramme d'architecture Kubernetes.

FAQ

Faut-il dessiner chaque job de CI ? Non. Regroupez les jobs en étapes et laissez le détail dans le fichier de CI. Ne dessinez un job à part que s'il sert de point de contrôle, comme un scan de sécurité qui bloque la mise en production.

Comment représenter les feature flags ? Comme un système distinct à côté de la production, avec un lien vers les services qui lisent les flags. Les flags changent le comportement sans déploiement : ils méritent leur propre ligne sur le diagramme.

Où placer les secrets sur le diagramme ? Montrez quel système détient quel identifiant et pour quoi faire, pas les secrets eux-mêmes. Pour la CI, indiquez si elle utilise des jetons OIDC de courte durée ou des clés stockées.

Faut-il un diagramme par dépôt ? En général, un diagramme par chemin de livraison. Si de nombreux services partagent le même pipeline, dessinez-le une seule fois et listez les services dans une note.

Comment garder le diagramme à jour ? Relisez-le quand le pipeline change, comme vous relisez le fichier de CI. Ajoutez un lien vers le diagramme en ligne dans le README du dépôt, pour qu'il n'en existe qu'une seule copie.

Commencez gratuitement — un siège, sans carte bancaire.