Arrêtez de traiter la gouvernance comme un système de tickets séparé

Vous venez de terminer une fonctionnalité. Le code est compilé, les tests sont verts, et le déploiement en staging semble sain. Et maintenant ? Dans de nombreuses équipes, l'étape suivante consiste à ouvrir un ticket, envoyer un e-mail à un comité consultatif des changements, et attendre. Peut-être des heures, peut-être des jours. Le pipeline reste inactif pendant que les gens courent après les approbations via un système complètement séparé.

Cette séparation entre le travail technique et la gouvernance crée des frictions. Les développeurs changent de contexte pour sortir de leurs outils. Les approbateurs examinent les modifications sans voir les résultats des tests ni l'historique des déploiements. Les pistes d'audit sont dispersées entre les fils d'e-mails, les commentaires de tickets et les messages de chat. Tout le monde trouve le processus lent, mais personne ne veut supprimer complètement les contrôles.

La solution n'est pas d'éliminer la gouvernance. C'est de l'intégrer directement dans le pipeline où le travail se fait déjà.

L'étape d'approbation manuelle : simple et auditable

L'intégration la plus simple est une porte d'approbation manuelle dans votre pipeline. Après que les builds et tests automatisés passent en staging, le pipeline se met en pause. Il attend qu'un humain examine les preuves et clique sur approuver avant de passer en production.

Le diagramme suivant compare l'ancienne approche avec la nouvelle :

Ce modèle fonctionne bien pour les changements normaux qui nécessitent un jugement humain mais pas une réunion complète du CAB. Le relecteur peut voir les résultats des tests, le diff et le statut du déploiement en un seul endroit. Il n'a pas besoin d'ouvrir un ticket séparé ni de chercher du contexte dans les logs de chat.

Voici un exemple minimal avec GitHub Actions qui met le pipeline en pause pour une approbation manuelle avant de déployer en production :

name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Deploy
        run: make deploy

Lorsque ce workflow s'exécute, GitHub Actions crée un déploiement vers l'environnement production. Si cet environnement nécessite un relecteur, le pipeline se met en pause et attend l'approbation avant d'exécuter l'étape Deploy. Le relecteur voit le commit, les résultats des tests et le diff dans l'interface GitHub.

Le détail crucial est que l'étape d'approbation doit enregistrer qui a approuvé, quand et quoi. Cela devient la piste d'audit. Des outils comme GitLab CI/CD, Jenkins et GitHub Actions prennent tous en charge cela nativement. Vous configurez les rôles qui peuvent approuver les déploiements en production (généralement les ingénieurs seniors ou les responsables techniques) et le pipeline l'applique.

Mais l'approbation manuelle n'est pas la bonne réponse pour chaque changement. Si chaque pull request nécessite qu'un humain clique sur un bouton, vous ralentissez les mises à jour à faible risque qui devraient passer automatiquement.

Policy-as-Code : laissez le pipeline décider

Pour les changements standards avec un risque prévisible, l'approbation manuelle devient un goulot d'étranglement. C'est là que le policy-as-code entre en jeu. Au lieu d'écrire des règles de gouvernance dans un document que les gens doivent mémoriser, vous les écrivez sous forme de code que le pipeline évalue automatiquement.

Une règle de policy-as-code pourrait dire : "Les modifications qui ne touchent que les fichiers de configuration frontend peuvent être déployées en production sans relecture humaine, à condition que tous les tests passent." Ou : "Toute modification qui ajoute une colonne à une table de base de données doit recevoir l'approbation d'un DBA avant de continuer."

Vous stockez ces règles dans un fichier à l'intérieur de votre dépôt, comme du code d'application. Le pipeline lit les règles, évalue le changement actuel par rapport à elles et décide s'il faut faire une pause pour relecture ou continuer automatiquement. Si une règle est violée, le pipeline échoue avec un message clair : "Cette modification ajoute une colonne à la table users, mais aucune approbation DBA n'a été trouvée."

L'équipe n'a pas à deviner si son changement est sûr. Le pipeline le lui dit, et il applique la règle de manière cohérente à chaque fois.

Combiner les deux approches

Les étapes d'approbation manuelle et le policy-as-code ne s'excluent pas mutuellement. Ils fonctionnent mieux ensemble. Le policy-as-code gère les décisions de routine automatiquement. Les portes d'approbation manuelle capturent les changements qui nécessitent un jugement humain.

Par exemple, votre pipeline pourrait avoir ces règles :

• Modifications de la documentation ou des actifs statiques : déploiement automatique après les tests.
• Modifications du code d'application avec une couverture de test complète et aucune migration de base de données : déploiement automatique après validation en staging.
• Modifications qui modifient les schémas de base de données : pause et nécessité d'approbation DBA.
• Modifications de la logique d'authentification ou de paiement : pause et nécessité d'approbation de l'équipe sécurité.
• Modifications pendant une période de gel (fin de trimestre, période de fêtes) : pause et nécessité d'approbation du responsable technique.

Le pipeline évalue le changement, applique les règles correspondantes et continue ou fait une pause. L'équipe n'a jamais à se rappeler quels changements nécessitent quelle approbation. Le pipeline le sait.

Pourquoi cela facilite l'audit

Lorsque la gouvernance vit à l'intérieur du pipeline, l'audit devient simple. Un auditeur n'a pas besoin de collecter des captures d'écran de fils d'e-mails ni de chercher dans les commentaires de tickets. Il regarde l'historique du pipeline pour un changement spécifique. L'enregistrement montre :

• Qui a fait le changement
• Qu'est-ce qui a été changé
• Quels tests ont été exécutés et s'ils ont réussi
• Quelles politiques ont été évaluées
• Qui a approuvé le changement et quand
• Quand le changement est arrivé en production

Tout est au même endroit. Chaque décision est horodatée et attribuée. Il n'y a pas d'écart entre ce que l'équipe prétend avoir fait et ce que le pipeline a enregistré.

Une checklist pratique pour intégrer la gouvernance dans votre pipeline

Avant de commencer à ajouter des portes d'approbation et des règles de politique, parcourez cette checklist avec votre équipe :

• Listez les types de changements que votre équipe effectue (configuration, schéma, code d'application, infrastructure, etc.)
• Pour chaque type, déterminez le niveau de risque : faible, moyen ou élevé
• Pour les changements à faible risque, écrivez des règles de policy-as-code qui permettent un déploiement automatique
• Pour les changements à risque moyen, ajoutez une étape d'approbation manuelle avec des critères clairs pour l'approbation
• Pour les changements à risque élevé, exigez plusieurs approbations ou un processus d'exception documenté
• Configurez qui peut approuver chaque niveau de changement dans votre outil de pipeline
• Testez le pipeline avec un changement réel pour confirmer que les portes fonctionnent comme prévu
• Examinez la piste d'audit après les premiers déploiements pour vérifier l'exhaustivité

La gouvernance n'est pas un ajout

Lorsque la gouvernance est intégrée dans le pipeline, elle cesse de ressembler à un processus supplémentaire qui ralentit tout le monde. Elle devient une partie du flux normal, comme l'exécution de tests ou la construction d'artefacts. L'équipe avance rapidement pour les changements à faible risque et obtient le bon niveau de relecture pour les changements à risque élevé. La piste d'audit est automatique et complète.

La prochaine fois que quelqu'un demande une approbation, n'ouvrez pas un ticket. Faites en sorte que le pipeline la demande à la place.