Nous utilisons l'IA pour écrire du logiciel plus vite, derrière des vérifications automatisées strictes qui décident ce qui peut être intégré. Les principes Honest Code, une barrière d'honnêteté et la mesure Slop Audit gardent l'espace de décision fini, pour qu'une suite de tests décidable puisse l'épuiser avant la production.
Par Adam Wasserman, chef de la technologieLes firmes qui activent des assistants de codage sans changer la forme de leur code obtiennent souvent le même résultat : vélocité en hausse, risque en hausse, et un faux sentiment de sécurité tiré de suites de tests au vert. Les modèles généralistes produisent par défaut des motifs lourds en classes et riches en état, qui rendent la vérification exhaustive impossible, même quand la couverture de lignes a l'air bonne.
Du code généré peut compiler, passer des tests superficiels, et encoder quand même le mauvais comportement — un risque de production invisible dans une simple revue de diff.
Objets mutables et répartition ouverte créent des séquences d'appels qu'aucune suite ne peut terminer. La couverture peut être au vert alors que le vrai espace de décision ne se ferme jamais.
Des E/S mêlées à la logique d'affaires forcent des tests qui s'approuvent eux-mêmes. Les défaillances se cachent jusqu'à l'intégration ou l'incident.
Demander au modèle de « faire attention » n'élimine aucune catégorie de défauts. Ce que la forme permet, le modèle continue de l'émettre.
L'inspection humaine après génération ne passe pas à l'échelle. Le volume croît plus vite que la capacité de raisonner sur chaque changement.
La couverture de lignes et les feux verts de l'intégration continue mesurent l'exécution de lignes, pas la capacité de la suite à épuiser les décisions qui comptent.
L'IA accélère autant la bonne structure que la mauvaise. Sans barrière, la mauvaise se compose en silence à chaque fusion.
Buckler ne traite pas le codage IA comme un robot conversationnel hébergé qui intègre tout ce qui a l'air plausible. Nous utilisons les assistants à l'intérieur d'une discipline de qualité intégrée : des principes nommés qui éliminent des catégories de défauts, une barrière d'honnêteté automatisée qui refuse le code malhonnête avant qu'il soit commité, et Slop Audit, qui évalue si la suite peut terminer l'espace, plus dix-huit dimensions de maturité de production en entreprise.
Un modèle de langage, seul, est un générateur semi-aléatoire. Chez Buckler, nous décidons quelle architecture de code est permise et comment elle doit être prouvée. La pile Open Honest (principes Honest Code, barrière Honest Framework et Slop Audit) est cette surface de contrôle.
L'idée, c'est le poka-yoke : rendre des classes entières de bogues impossibles à construire, et garder les tests automatisés capables de suivre le volume de génération.
Les ingénieurs utilisent l'IA dans le dépôt, contre des contrats et des formes de données déclarés, et non comme auteur incontrôlé de l'architecture.
P01–P25 nomment les catégories de défauts à éliminer d'emblée : répartition ouverte, gros état, E/S mêlées, simulacres dans le noyau, et plus. Les principes disent au modèle comment les éviter dès le départ.
honest-check refuse le code structurellement malhonnête pendant que l'IA code ; honest-test bloque les commits qui échouent à la norme. Pas de fusion « presque honnête ».
La couche 1 évalue si la base de code peut être vérifiée (ratio d'état mutable, espace de décision, déterminisme). La couche 2 évalue les dix-huit dimensions d'entreprise ci-dessous. Une mesure objective, pas une opinion.
Les garde-fous par requête limitent ce qu'on demande au modèle de dire. Le modèle les traite comme des suggestions. Buckler ajoute une étape différente : quand du code est produit, des vérifications mécaniques examinent ensemble le code et les tests, et refusent les commits qui laissent un espace de décision ouvert ou brisent d'autres motifs nommés.
Le code qui ne peut être vérifié n'est pas accepté. Du code plausible sans vérification objective, c'est ce qui met le « feeling » dans le « codage au feeling ».
Un codage assisté par l'IA sûr est une propriété de l' architecture du code. Des noyaux purs, des E/S seulement à la frontière, des tables de répartition fermées et des erreurs qui voyagent dans les valeurs de retour : c'est ainsi que nous trouvons les fautes et empêchons des classes entières de bogues d'être écrites.
N'importe qui peut générer une démo qui passe en un après-midi. Ce qui compte, c'est si le même changement reste décidable à mesure que le système grandit, et si un feu vert d'intégration continue signifie que la suite a terminé l'espace, ou seulement parcouru un mince sentier dans un espace ouvert.
Au-delà de la couche 1, la couche 2 de Slop Audit note dix-huit dimensions de maturité de production. Chacune a un seuil publié, une procédure d'inspection mécanique et une notation Présent / Partiel / Absent. La liste ci-dessous provient de l'aide-mémoire de la spécification ouverte de Slop Audit (spec/dimensions/00-quick-reference.md). Les dix-huit sont rédigées en version v0 ; l'étalonnage sur le jeu de validation est un travail en cours, pas une liste de remplissage.
Les étiquettes de cycle de vie sont les catégories qu'utilise l'instrument (sécurité, données, ingénierie de conformité, exploitation, architecture, gouvernance, etc.). Le seuil en une ligne est la barre du secteur qu'applique l'évaluateur.
L'instrument Slop Audit revendique six familles de cadres. Cette revendication est détenue à un seul endroit dans le dépôt ouvert (spec/04-compliance-frameworks.md), ancrée dans l'expérience naturelle publiée. Une dimension qui cite un cadre signifie que sa preuve aiderait un évaluateur qui s'interroge sur ce contrôle. Cela ne signifie pas que l'instrument audite ce cadre, et un score réussi n'est jamais, à lui seul, une conclusion de conformité.
| Cadre | Couverture dans l'instrument | Comment le lire |
|---|---|---|
| NIST SP 800-53Documenté | 18 dimensions sur 18 | Appuie la preuve pour des familles de contrôles comme le contrôle d'accès, l'audit, la protection des systèmes et des communications et le développement sécurisé (SA/CM/AU/AC/SC selon la dimension). |
| SOC 2 (TSC)Documenté | 11 dimensions sur 18 | S'aligne sur les thèmes courants des Trust Services (accès logique, gestion des changements, surveillance, communication de disponibilité) là où les fichiers de dimension les citent. |
| OWASP (ASVS, API Top 10, SAMM)Documenté | 3 dimensions sur 18 | Citations étroites et explicites (par exemple la consommation de ressources non limitée pour la limitation de débit). |
| DORADocumenté | 3 dimensions sur 18 | Cité là où les capacités de livraison et d'exploitation correspondent ; pas un score DORA global. |
| CISDocumenté | 2 dimensions sur 18 | Cité pour les référentiels de secrets et de conteneurs/orchestration là où les fichiers les nomment. |
| CNCFDocumenté | 2 dimensions sur 18 | Cité là où les orientations infonuagiques natives sont pertinentes dans les entrées de dimension. |
Les fichiers de dimension citent aussi d'autres régimes (par exemple BSIF B-13, ISO/IEC 25010, PCI DSS, RGPD, Loi 25 du Québec). Ces citations existent aujourd'hui dans le catalogue mais ne font pas partie des six revendiquées par l'instrument tant qu'un catalogue publié ne les aura pas cartographiées dimension par dimension de la même façon. Nous ne les traitons pas comme des certifications que Buckler « respecte ».
Alignement illustratif (pas une revendication documentée de l'instrument) : le motif de cycle de développement à barrières (spécification avant le code, vérifications d'honnêteté avant commit, barrières de qualité en intégration continue) est le genre de thème de contrôle qu'on retrouve aussi dans le développement sécurisé de type NIST SSDF et la gestion des changements de type ISO/SOC. Là où une dimension cite déjà NIST SSDF ou SOC 2 CC8.1, c'est documenté ; tout langage plus large de « maturité du cycle de développement » au-delà de ces citations n'est qu'illustratif.
Parce que la génération se trouve derrière des principes, une barrière d'honnêteté et une mesure ouverte de ce que la suite peut terminer, la posture de risque s'énonce simplement : l'IA peut rédiger ; la structure et la suite décident de ce qui est intégré ; le risque résiduel est noté au grand jour.
Veille constante sur les assistants, les modèles et l'outillage d'édition à mesure qu'ils mûrissent.
Une posture indépendante de l'outil : la barrière et la mesure restent ; le générateur peut changer.
Analyse structurelle et vérifications comportementales au commit, pas des conseils de style facultatifs.
Assertions sur fonctions pures préférées aux simulacres dans le noyau.
Les contrats et formes de données contraignent l'entrée de l'IA ; la barrière contraint sa sortie.
La couche 1 de Slop Audit rapporte si le code peut être vérifié, et échoue en mode fermé quand l'analyse n'est pas résolue. Elle ne prétend pas que la suite a déjà tout vérifié.
Les scores de dimension de la couche 2 sont des artefacts de preuve pour les discussions de risque et d'audit, pas un substitut à une opinion de conformité délimitée.
Une gouvernance efficace de l'IA dans le codage n'est pas qu'un cartable de politiques. Ce sont des rôles, des barrières et des documents qui correspondent à la façon dont le travail est réellement livré. Établir la discipline tôt, c'est ce qui empêche la vélocité de l'IA de devenir une dette sans propriétaire, et ce qui fait de l'adoption, de la préparation à l'audit et de la livraison un seul et même projet.
honest-check / honest-test refusent la structure malhonnête au moment de l'édition et du commit. L'intégration continue porte la même barre. Ce qui ne passe pas la barrière ne fusionne pas, peu importe à quel point la sortie du modèle semblait plausible.Des principes, une barrière d'honnêteté et une mesure ouverte de ce qui peut être prouvé — pas l'espoir d'une requête.