Quand le pipeline décide qui approuve un déploiement

Imaginez ceci : un développeur corrige une faute de frappe dans une page de documentation. Le changement tient en une ligne, aucune logique n'est affectée, aucune base de données n'est touchée. Pourtant, le processus de déploiement exige toujours deux approbations, une attente de 30 minutes en staging, et un feu vert du responsable technique. La correction qui devrait mettre cinq minutes à atteindre les utilisateurs finit par prendre une demi-journée.

Imaginez maintenant l'inverse : un développeur modifie un script de migration de base de données qui pourrait verrouiller une table en production. Le même pipeline traite ce changement exactement comme la correction de faute de frappe. Aucune revue supplémentaire, aucun contrôle additionnel. Le changement passe comme une lettre à la poste, et l'équipe ne découvre le problème que lorsque les requêtes commencent à expirer.

Ces deux scénarios sont problématiques, mais pour des raisons opposées. Le premier ralentit les changements sûrs. Le second laisse passer des changements dangereux. Le problème, c'est que la plupart des pipelines de déploiement appliquent les mêmes règles à chaque changement, indépendamment de ce qui a réellement été modifié.

Pourquoi une approbation unique ne fonctionne pas

La plupart des équipes commencent avec un modèle d'approbation simple : chaque déploiement nécessite une revue. Cela fonctionne quand l'équipe est petite et que chaque changement est significatif. Mais à mesure que la base de code grandit, le modèle se brise. Une retouche CSS et un refactoring du module de paiement exigent tous deux la même validation. Les développeurs commencent à contourner le système, en regroupant les changements pour réduire le nombre de déploiements, ou pire, en sautant complètement les revues parce que le processus semble bureaucratique.

Le vrai problème, c'est que le risque n'est pas uniforme. Un changement dans un fichier README comporte un risque opérationnel quasi nul. Un changement dans une migration de base de données ou un module d'authentification comporte un risque significatif. Les traiter de la même manière signifie que vous êtes soit trop strict pour les changements sûrs, soit trop laxiste pour les changements risqués.

Comment un pipeline peut évaluer le risque automatiquement

Au lieu de compter sur les humains pour juger chaque changement, vous pouvez apprendre à votre pipeline à évaluer le risque en fonction des fichiers modifiés. C'est ce qu'on appelle le scoring de risque, et cela fonctionne en définissant des règles qui attribuent des points aux changements en fonction de leur portée.

Un ensemble simple de règles pourrait ressembler à ceci :

Voici comment cette logique se traduit dans une configuration de pipeline GitLab CI :

stages:
  - test
  - deploy

deploy:
  stage: deploy
  script:
    - echo "Déploiement en production..."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "db/**/*"
        - "config/**/*"
      when: manual
      allow_failure: false
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "README.md"
      when: on_success
    - when: on_success

• Changements dans les fichiers docs/ ou README.md : 0 points
• Changements dans les fichiers de configuration (.env, config/) : 3 points
• Changements dans la logique métier dans src/ : 7 points
• Changements dans les modules de paiement ou d'authentification : 20 points
• Changements dans les fichiers de migration de base de données : 25 points

Le pipeline analyse la pull request ou le commit, vérifie chaque fichier modifié par rapport à ces règles, et additionne le score total. Ce score détermine ensuite la suite des événements.

Associer les scores de risque aux politiques de déploiement

Une fois que le pipeline a un score de risque, il peut appliquer différentes politiques en fonction du résultat. Une configuration typique pourrait avoir trois niveaux :

Le diagramme suivant illustre comment le pipeline associe les scores de risque aux politiques de déploiement :

Risque faible (score 0-5) : Le changement peut aller directement en production sans aucune approbation manuelle. Le pipeline exécute les tests automatisés, et s'ils passent, le déploiement se poursuit. Cela couvre les corrections de documentation, les modifications mineures de configuration, ou les refactorings qui ne touchent pas aux chemins critiques.

Risque moyen (score 6-15) : Le changement nécessite une approbation d'un pair ou d'un ingénieur senior. Le pipeline fait une pause après la réussite des tests et attend une validation manuelle avant de continuer vers la production.

Risque élevé (score 16+) : Le changement nécessite deux approbations et doit passer au moins une heure en staging avec des contrôles de surveillance actifs. Le pipeline déploie d'abord en staging, exécute des tests de fumée, vérifie les taux d'erreur et la latence, et seulement ensuite autorise la promotion finale en production.

Ces seuils ne sont pas figés. Différents environnements peuvent avoir des règles différentes. Dans un environnement de développement, vous pouvez tout traiter comme à risque faible car il n'y a pas d'utilisateurs réels. En staging, vous pouvez relever légèrement les seuils. En production, vous appliquez les règles les plus strictes.

Le vrai bénéfice, c'est la cohérence, pas la perfection

Le scoring de risque ne sera jamais parfaitement précis. Un changement d'une seule ligne dans une fonction utilitaire pourrait casser quelque chose d'inattendu si cette fonction est appelée à de nombreux endroits. Un gros refactoring qui touche beaucoup de fichiers pourrait en fait être sûr s'il ne fait que renommer des variables.

Mais la perfection n'est pas le but. Le but est de remplacer le jugement humain ad-hoc par un processus cohérent et transparent. Sans scoring de risque, chaque déploiement déclenche un débat : « Est-ce que ça nécessite une approbation ? Qui devrait la faire ? Est-ce assez risqué pour justifier un passage en staging ? » Ces débats font perdre du temps et créent de l'incohérence. Une semaine, un petit changement passe sans problème, la semaine suivante, le même type de changement est bloqué.

Avec le scoring de risque, les règles sont écrites et appliquées automatiquement. L'équipe peut débattre des règles une fois, lors de leur mise en place, au lieu de débattre pour chaque déploiement. Et comme les règles sont transparentes, l'équipe peut les revoir et les ajuster au fil du temps, en apprenant quels types de changements causent réellement des problèmes.

Comment cela change le comportement de l'équipe

Le contrôle de déploiement basé sur le risque ne se contente pas d'automatiser les approbations. Il change la façon dont les développeurs pensent la structure du code. Quand l'équipe sait que tout changement dans db/migrations/ déclenche automatiquement une politique à haut risque, elle devient plus prudente sur ce qui se retrouve dans ce dossier. Elle pourrait séparer les changements de schéma de base de données des scripts de migration de données, afin qu'un simple backfill de données ne déclenche pas la même scrutiny qu'une altération de schéma.

Cela encourage également une meilleure modularisation. Si une équipe remarque que les changements dans un module particulier obtiennent toujours un score de risque élevé, elle pourrait refactoriser ce module pour isoler les parties vraiment sensibles des mises à jour de routine. Avec le temps, la base de code devient plus consciemment structurée autour des limites de risque.

Checklist pratique pour mettre en place le scoring de risque

Si vous souhaitez implémenter cette approche, voici une checklist de départ :

• Identifiez les dossiers et motifs de fichiers qui représentent différents niveaux de risque dans votre base de code
• Définissez un système de scoring avec des valeurs de points claires pour chaque motif
• Fixez des seuils pour les risques faible, moyen et élevé dans chaque environnement
• Définissez la politique de déploiement pour chaque niveau de risque (approbations nécessaires, temps en staging, contrôles de surveillance)
• Implémentez la logique de scoring de risque dans la configuration de votre pipeline CI/CD
• Exécutez le scoring sur chaque pull request et enregistrez les résultats pour plus de visibilité
• Révisez les règles de scoring après un mois et ajustez-les en fonction de ce que vous avez appris

Le pipeline devient un décideur

Quand vous ajoutez un contrôle de déploiement basé sur le risque, votre pipeline cesse d'être un simple outil qui exécute des commandes. Il devient un système de décision qui évalue les changements, applique des règles et détermine le chemin approprié vers la production. Le pipeline ne remplace pas entièrement le jugement humain, mais il réserve l'attention humaine pour les changements qui en ont réellement besoin.

Il ne s'agit pas de supprimer le contrôle. Il s'agit d'appliquer le bon niveau de contrôle au bon changement. Les petits changements sûrs avancent vite. Les changements importants et risqués reçoivent l'attention qu'ils méritent. Et l'équipe cesse de gaspiller de l'énergie à débattre de ce qui devrait être évident.