11-5 · Chapitre 11 · 5 min de lecture

Pourquoi enregistrer les approbations et les preuves est plus important qu’obtenir un « oui »

Une approbation verbale sans trace écrite peut causer des conflits lors d’un incident. Découvrez comment capturer qui a approuvé, quand et sur quelles preuves pour un audit trail fiable.

Pourquoi enregistrer les approbations et les preuves est plus important qu’obtenir un « oui »

Vous venez d’obtenir l’approbation verbale de votre manager pour déployer une modification de base de données tard dans la nuit. Il a dit « vas-y », vous avez lancé le déploiement, et tout semblait normal. Une semaine plus tard, quelque chose casse. Pendant le post-mortem, vous dites que votre manager a approuvé. Votre manager dit ne se souvenir d’avoir rien approuvé de tel. Vous avez désormais deux problèmes : le problème technique à l’origine de l’incident, et un litige sur qui a autorisé le changement.

Ce scénario se produit plus souvent que la plupart des équipes ne l’admettent. L’approbation a eu lieu, mais il n’y a aucune trace. Aucune preuve de qui a dit oui, quand il l’a dit, ou ce qu’il a vu avant d’accepter. Sans cette trace, l’approbation n’a jamais existé.

Ce qu’un véritable enregistrement d’approbation doit capturer

Un enregistrement d’approbation complet répond à trois questions. Si l’une d’elles manque, votre piste d’audit a un trou qui pourrait causer de sérieux problèmes plus tard.

Voici à quoi pourrait ressembler un enregistrement d’approbation complet dans un journal d’audit de pipeline :

{
  "change_id": "DEPLOY-2024-11-05-142",
  "approver": {
    "name": "alice.chen",
    "role": "engineering_manager"
  },
  "timestamp": "2024-11-05T14:30:00Z",
  "evidence": [
    {
      "type": "test_results",
      "url": "https://ci.internal/pipeline/1234/test-report"
    },
    {
      "type": "security_scan",
      "summary": "0 critical, 2 high, 5 medium findings - all waived per policy"
    },
    {
      "type": "change_request",
      "url": "https://tickets.internal/CR-7890"
    }
  ]
}

Qui a approuvé

Le pipeline doit enregistrer l’identité de la personne qui a donné l’approbation. Pas seulement un nom, mais aussi son rôle dans l’équipe. Était-ce le lead technique, le responsable engineering, ou un DBA ? Le rôle est important car il indique si cette personne avait l’autorité d’approuver ce type de changement.

Plus important encore, le système doit vérifier que l’approbation vient bien de cette personne, et non de quelqu’un d’autre utilisant son compte. C’est pourquoi les workflows d’approbation doivent passer par des systèmes intégrés à l’authentification de votre équipe, et non par des messages chat ou des e-mails qui peuvent être facilement falsifiés ou transférés. Si quelqu’un peut copier-coller un message « approuvé » depuis un fil Slack, vous n’avez pas un système d’approbation. Vous avez un jeu de captures d’écran.

Quand elle a été approuvée

L’horodatage doit inclure les minutes et le fuseau horaire. Cela peut sembler excessif jusqu’à ce que vous deviez reconstituer la séquence des événements lors d’une enquête d’incident.

Considérez cette chronologie :

Changement soumis à 14:00
Approbation donnée à 14:30
Déploiement en production à 14:45
Incident détecté à 15:10

Avec des horodatages propres, vous voyez exactement comment les choses se sont déroulées. Sans eux, vous devinez si l’approbation a eu lieu avant ou après le déploiement. Une approbation qui arrive après le déploiement n’est pas une approbation. C’est une notification déguisée en gouvernance.

Sur quelles preuves ils se sont basés

C’est l’élément que la plupart des équipes oublient. Quelqu’un a approuvé un changement, mais qu’a-t-il réellement vu avant de cliquer sur « approuver » ? A-t-il examiné les résultats des tests ? Lu le changelog ? Vérifié si le changement affectait d’autres systèmes ? Ou a-t-il simplement fait confiance au fait que tout allait bien ?

Le pipeline doit capturer les preuves qui ont éclairé la décision. Cela peut inclure :

Un lien vers l’exécution du pipeline montrant que toutes les portes ont été passées
Une capture d’écran des résultats du scan de sécurité
Le document de demande de changement examiné
Un résumé de ce qui a été vérifié et confirmé

En capturant ces preuves, l’approbation cesse d’être un tampon en caoutchouc pour devenir une décision vérifiable. N’importe qui peut revenir plus tard et voir exactement ce qui était connu au moment de l’approbation, pas seulement que quelqu’un a dit oui.

Construire la piste d’audit

Ces trois informations forment ensemble votre piste d’audit. Une piste d’audit est l’enregistrement complet de ce qui est arrivé à un changement du début à la fin : qui l’a fait, qui l’a examiné, quelles portes il a passées, qui l’a approuvé, quand il a été déployé, et si le déploiement a réussi ou échoué.

Une piste d’audit complète sert deux objectifs. D’abord, elle satisfait aux exigences de conformité. Que votre entreprise suive des politiques internes ou des réglementations externes, disposer d’un enregistrement clair de chaque changement et de qui l’a autorisé est souvent obligatoire.

Ensuite, et de manière plus pratique, elle rend les enquêtes d’incident plus rapides et moins stressantes. Quand quelque chose tourne mal, vous n’avez pas besoin de retrouver les gens et de demander « qui a fait ça ? » ou « pourquoi cela a-t-il été autorisé ? » Les réponses sont déjà enregistrées. Vous pouvez vous concentrer sur la résolution du problème au lieu de reconstituer ce qui s’est passé.

Le mettre en pratique

La plupart des outils CI/CD modernes capturent déjà une partie de ces informations. GitLab CI/CD, GitHub Actions, et Jenkins avec les bons plugins peuvent enregistrer qui a approuvé un changement et quand. Mais la partie preuve nécessite généralement un effort manuel de la part de la personne qui approuve.

La solution est simple mais demande de la discipline : prenez l’habitude qu’avant d’approuver, l’approbateur ajoute un commentaire avec un lien ou un résumé de ce qu’il a examiné. Sans cette habitude, vos enregistrements d’approbation diront simplement « approuvé » sans contexte. C’est à peine mieux que de n’avoir aucun enregistrement.

Certaines équipes vont plus loin en intégrant la collecte de preuves directement dans le pipeline. L’étape d’approbation peut afficher un résumé des résultats de tests, des conclusions du scan de sécurité, et des détails du changement directement dans l’interface d’approbation. L’approbateur voit tout ce dont il a besoin sans quitter le pipeline, et le système enregistre ce qui a été affiché. Cela élimine le besoin de commentaires manuels et rend la capture des preuves automatique.

Une checklist rapide pour vos enregistrements d’approbation

Si vous mettez en place ou révisez votre processus d’approbation, passez en revue ces points :

Le pipeline enregistre-t-il l’identité et le rôle de l’approbateur ?
L’horodatage est-il suffisamment précis pour reconstituer les séquences d’événements ?
Les preuves qui ont éclairé l’approbation sont-elles capturées automatiquement ou manuellement ?
Quelqu’un qui examine la piste d’audit six mois plus tard peut-il comprendre pourquoi ce changement a été approuvé ?
Le système d’approbation est-il intégré à l’authentification de votre équipe, et non à un simple message chat ?

L’essentiel

Une approbation sans trace n’est pas une approbation. C’est une conversation dont chacun peut se souvenir différemment. En capturant qui a approuvé, quand, et sur quelles preuves, vous transformez un « ok, vas-y » informel en une décision qui peut être examinée, auditée et défendue. C’est la différence entre un processus qui semble avoir des contrôles et un qui en a réellement.