Notre méthode
Des agents d’IA font le travail. Des personnes prennent les décisions.
Nous appelons notre méthode de livraison l’AI Dark Factory : des agents écrivent, testent et révisent le code en parallèle, et des personnes tranchent tout ce qui comporte un risque.
Pourquoi parler de « dark factory »
En fabrication, une « dark factory » est une usine assez automatisée pour fonctionner lumières éteintes. Chez nous, le nom désigne le niveau d’automatisation. Les décisions importantes restent entre les mains de personnes.
Les agents font le travail répétitif qui peut être vérifié : lire le code, écrire les tests, compiler et réviser. Les personnes gardent les décisions qui comportent un risque : ce qui est développé, ce qui est fusionné, et tout ce qui touche aux identifiants, à l’argent ou aux données des clients.
Douze étapes et un contrôle avant la fusion
Aujourd’hui, chaque modification suit la même chaîne. Une modification qui échoue à une vérification retourne au développement.
-
Planifier
- Étape 03 Questions de conception et de sécurité Données, accès et exposition sont nommés avant toute ligne de code.
-
Développer
-
Valider
- Étape 09 Compilation et tests réussis Types, lint, compilation et tests sur la dernière version du code.
-
Livrer
- Contrôle de fusion : des règles, et un humain en cas de doute.
- Étape 11 Vérification en ligne La version en service est vérifiée ; un échec lance un retour en arrière.
Des personnes s’occupent des identifiants, des approbations et de l’argent.
-
Conclure
- Étape 12 Journal, documentation et rapport Journal des changements en langage clair, aide à jour, rapport d’une page.
-
- Les constats retournent au développement
- Échec de la vérification en ligne : retour en arrière lancé aussitôt
- Les leçons retournent dans les notes de terrain
- Étape d’un agent d’IA
- Décision humaine
- Contrôle réussite ou échec
Ce qui se passe à chaque étape
-
Une demande écrite d’abord
Chaque bogue, fonctionnalité ou suivi fait l’objet d’une demande écrite (ticket). Avant le début des travaux, les demandes et les demandes de fusion (pull requests) liées sont repérées et regroupées, et ce qui manque est consigné. Chaque ligne de code remonte à une demande que tout le monde peut lire.
-
Notes de terrain
Les agents consultent un registre commun des leçons tirées des travaux précédents : particularités de compilation, surprises au déploiement, approches qui ont échoué. Ils vérifient aussi les travaux en cours pour que deux efforts n’entrent pas en collision.
-
Questions de conception et de sécurité
Des agents éclaireurs lisent le code, les demandes et les plans du produit, puis deux ou trois options de conception sont rédigées et critiquées. Chaque conception répond d’emblée à quatre questions : qui a le droit d’appeler cette fonction, à qui appartiennent les dossiers qu’elle lit ou modifie, à quelle identité elle se fie et quelles données sortent du système.
-
Tests écrits d’abord
Un agent distinct, qui ne voit que la demande, écrit des tests d’acceptation qui échouent au départ. L’agent qui développe ne peut pas les modifier ; si un test change, la raison doit être énoncée et acceptée à la revue.
-
Développement en parallèle
Plusieurs agents développent en même temps, chacun dans sa propre copie isolée du code et de la base de données. Tout nouvel élément qui s’exécute reçoit au moins un test qui passe par le vrai point d’entrée et vérifie ce qu’un utilisateur verrait.
-
Évaluations honnêtes
Quand une fonctionnalité classe, choisit ou rédige du contenu, elle est notée selon un seuil établi d’avance (une évaluation). Les données de test sont divisées, et le jeu réservé, des exemples gardés de côté jusqu’à la fin, ne sert qu’une fois, pour le résultat final. Les résultats sont comparés sur plusieurs exécutions.
-
Vérification adversariale
Sur les parcours sensibles comme la connexion, les permissions, la séparation des clients ou tout ce qui envoie des données à l’extérieur, un nouvel agent reçoit seulement la modification et la demande, et tente de la briser. Chaque faille réelle est corrigée, et son test reste dans la suite.
-
Revue indépendante
Chaque modification est révisée pour l’exactitude, la sécurité et l’isolation des clients, la qualité des tests, l’expérience utilisateur et la cohérence avec le code existant. Les constats sont vérifiés avant d’être retenus, et les correctifs sont confiés à un nouvel agent.
-
Compilation et tests réussis
Une compilation réussie veut dire que toutes les vérifications automatisées ont passé : vérification des types, lint, formatage, compilation et tests, exécutés sur la dernière version du code. Une suite complète s’exécute chaque nuit, et un échec ouvre automatiquement une demande.
-
Fusion contrôlée
Une modification n’est fusionnée que si la revue l’a approuvée, que chaque constat vérifié est corrigé, que la compilation est réussie et qu’elle n’apporte aucun changement risqué à la base de données ou à l’infrastructure. En cas de doute, un membre de l’équipe tranche. Les déploiements passent uniquement par une fusion approuvée.
-
Vérification en ligne
Après la fusion, nous confirmons que la nouvelle version est bien celle qui est en service, puis nous vérifions la fonctionnalité dans un environnement de test en ligne. Si cette vérification échoue, un retour en arrière est lancé aussitôt.
-
Journal, documentation et rapport
Chaque changement qu’un utilisateur pourrait remarquer obtient une entrée au journal des changements qui commence par une phrase simple. Les pages d’aide sont mises à jour, les environnements temporaires sont supprimés, et un rapport d’une page présente ce qui a été fait, les résultats honnêtes et tout ce qui demande une intervention humaine.
Les règles de la chaîne
-
Mesurer plutôt qu’affirmer
Les chiffres viennent d’exécutions réelles. Si une cible n’est pas atteinte, le rapport le dit.
-
Bien testé vaut mieux que vite fait
La vitesse vient de l’automatisation. Chaque étape s’exécute quand même.
-
Les identifiants, les approbations et l’argent relèvent de personnes
Les agents ne manipulent jamais de mots de passe, n’approuvent jamais d’accès, ne créent pas de ressources infonuagiques et ne modifient pas la facturation.
-
La sécurité par défaut
Chaque modification précise qui peut l’appeler, quelles données elle touche et ce qui sort du système.
-
Chaque bogue échappé est retracé
Quand un bogue atteint les utilisateurs, nous trouvons la vérification qui aurait dû le détecter, et nous l’ajoutons.
Ce que cela change pour nos clients
-
Des livraisons plus rapides, sans sauter la revue
Les agents travaillent en parallèle. Chaque modification passe quand même par les tests et une revue indépendante, et les modifications sensibles subissent aussi une vérification adversariale.
-
Chaque modification est traçable
Demande, tests, revue, compilation, journal des changements. Vous pouvez toujours demander ce qui a changé et pourquoi, et obtenir une vraie réponse.
-
Des personnes approuvent ce qui compte
Vos données, vos identifiants et votre argent ne dépendent jamais d’un agent laissé sans supervision.
-
Moins de surprises après une mise à jour
Les tests sont écrits avant le code, les modifications sensibles sont attaquées avant la mise en production, et la version en service est vérifiée après la fusion.
-
Des mises à jour en langage clair
Chaque entrée du journal des changements commence par ce que vous pouvez maintenant faire, dans des mots qu’un client comprend.
Vous aimeriez appliquer cette méthode à votre propre code ?
Nous aidons les équipes de développement à mettre en place les mêmes pratiques : demandes écrites, tests d’abord, revue indépendante et fusions contrôlées, avec des agents d’IA qui s’occupent du travail répétitif.