Système d'exploitation
On arbitre d'habitude entre la vitesse et le contrôle. Sous supervision, cet arbitrage n'existe pas. La question que pose une due diligence technique n'est pas à quelle vitesse vous livrez, mais si vous pouvez démontrer pourquoi chaque changement était sûr.
Voici le système aujourd'hui en place chez Togethrust, sur cinq dépôts. C'est aussi ce que le quatrième mouvement d'un audit, transmettre, laisse tourner à l'équipe d'un fondateur.
Pourquoi ça compte
Que les constats reposent sur le code, et non sur un échantillon.
Que la conformité est un contrôle que l'on peut montrer, pas un document que l'on peut produire.
Que l'équipe saura le faire tourner quand celui qui l'a construit n'y touchera plus.
La règle
Deux dépôts énoncent la même règle, avec leurs propres mots, sans s'être concertés. L'un dit qu'une revue qui n'a pas pu tourner ne doit jamais ressembler à une revue passée, et fait sortir en erreur tout chemin qui ne produit pas de verdict. L'autre l'énonce comme un standard : un contrôle doit avoir un mode d'échec distinguable de son succès.
Cette règle a été apprise, pas conçue. Un pipeline qui remontait le statut de sa dernière commande a laissé une suite de tests en échec annoncer un succès, et a mis une build cassée sur le tronc.
L'outil qui vérifie a été reconstruit pour qu'il ne puisse pas annoncer un succès sur une exécution en échec.
Un lecteur de due diligence technique ne demande pas combien de contrôles vous exécutez. Il demande ce qui se passe quand l'un d'eux ne peut pas s'exécuter.
Un exemple
Un hook devait écrire une ligne à chaque fin de tâche de fond. Un audit a trouvé dix-huit fichiers de journal sur le disque, tous vides, sur un mois. Le hook sortait en succès depuis le début.
La note écrite à ce moment-là nomme exactement le problème : vérifier que le hook sort en code zéro, c'est l'assertion qui a échoué à échouer ici.
Il a été supprimé plutôt que réparé, parce que personne n'avait jamais lu ces fichiers et que la plateforme remontait déjà les mêmes compteurs. La décision a été écrite et close avec son résultat, plutôt que retirée.
Ce n'était pas un constat de routine. C'est l'installation de la couche de contrôle qui l'a fait apparaître, avec plusieurs autres instruments qui annonçaient un succès sans rien faire.
La chaîne
Une passe de revue s'exécute sur le changement indexé avant que le commit n'existe, et le bloque sur tout constat significatif. Une revue qui échoue est traitée comme un échec, jamais comme un succès.
Une seule commande exécute toute la suite et n'annonce un succès que si chaque contrôle passe. Les contrôles sont eux-mêmes couverts par des tests automatisés, exécutés à leur modification et chaque nuit, pour qu'un contrôle qui cesse discrètement de fonctionner soit détecté et non supposé.
Un contrôle est introduit en consultatif, puis promu bloquant une fois que ses constats l'ont mérité. Un contrôle qui se déclenche à chaque commit est un contrôle que l'on apprend à contourner.
La fusion part automatiquement vers un environnement de pré-production. Atteindre la production est une action distincte qui requiert une personne nommée, et l'automatisation planifiée s'arrête à cette frontière plutôt que de la contourner.
Auditabilité
Les formats de requête et de réponse vivent dans un paquet versionné unique, compilé par le serveur et par trois clients : un changement de format qui casserait un appelant échoue à la compilation plutôt qu'en production.
La contribution de l'assistant est enregistrée dans les métadonnées de commit plutôt qu'absorbée silencieusement : on peut établir plus tard quels changements un assistant a touchés.
La journalisation d'audit a sa propre couche de stockage, son test de contrat et son test d'intégration sur une vraie base. Le stockage a été rendu expurgeable une fois établi que l'application pouvait y écrire des données personnelles, plutôt que sur la base d'une mesure des lignes existantes.
Les alertes vivent dans le gestionnaire de versions, avec des seuils argumentés à partir d'incidents mesurés plutôt que pris par défaut.
Limites
Chaque affirmation ci-dessus a une limite. Les voici, pour que rien sur cette page n'ait à être cru sur parole.
L'essentiel de tout cela est récent, et délibérément. C'est le système aujourd'hui en place, pas un historique.
Les scanners s'exécutent. Les scanners ne bloquent pas.
L'approbation de production est une pause imposée, avec une personne nommée. Ce n'est pas une séparation des tâches.
Les champs sensibles sont classifiés. Classifier n'est pas appliquer, et cette page ne prétend pas le contraire.
Un audit tech 360° par trimestre. Quinze heures, périmètre fixe, un rapport noté et une feuille de route 90 jours.
Appel diagnostic gratuit d'abord • Une entreprise à la fois
Parlez-moi de votre entreprise →Ou écrivez-moi à khaled.souf@gmail.com