Comment développe-t-on, seul, un logiciel dont chaque chiffre doit pouvoir être prouvé ?
Ma réponse, après des mois de pratique : on ne développe pas seul. On applique la méthode décrite par le patron d’NVIDIA en début d’année… 1 humain travaillant en équipe avec X IA (lui avait dit 10 :))
On organise le doute.
Sur CoDIR-IA, nous sommes trois autour de la table.
Le développeur : une IA, responsable de tout le code livré.
Pas de brouillon, pas de candidat approximatif : ce qu’elle livre, elle le signe.
L’auditeur : une autre IA, indépendante, dont le rôle est de casser.
Elle ne voit pas le code s’écrire ; elle reçoit une archive scellée par empreinte, la reconstruit bit à bit, et cherche la faille.
L’arbitre : moi. L’Humain 😊
Je ne tranche jamais sur une promesse.
Je rejoue, je teste sur l’interface réelle, et je prononce le GO ou le NO-GO.
Trois règles rendent l’ensemble honnête :
1. Reproduire avant de patcher. Un bug signalé doit d’abord être reproduit à l’identique. Sinon, on corrige un fantôme.
2. Zéro fausse certification. « Analysé » ne vaut jamais « prouvé ».
Seul ce qui est prouvé justifie un GO.
3. Tout est scellé.
Chaque livraison est une archive à empreinte unique, reconstruite et revérifiée. Pas de « ça marchait chez moi ».
Cet été, la boucle a produit dix-sept correctifs successifs sur un même chantier – chacun répondant à un constat d’échec documenté par l’auditeur.
Et puis un jour, l’auditeur a vu la solution plus clairement que le développeur. Alors nous avons inversé les rôles : celui qui détient la généralisation l’implémente, l’autre prend le marteau.
Au bout de la boucle, l’audit croisé a rendu son verdict : GO, aucun défaut disqualifiant.
Ce n’est pas « l’IA code pour moi ».
C’est une organisation où personne – humain ou IA – n’est cru sur parole.
Jeudi prochain : pourquoi cet outil préfère se bloquer plutôt qu’inventer.
#CoDIRIA #IA #GenieLogiciel #Qualite #BuildInPublic
