CounterProof est une pratique de revue adversariale indépendante pour les bases de code modernes — le code écrit par des machines avant tout. Nous livrons la seule chose que vous ne pouvez pas produire en interne : une évaluation de sécurité indépendante, signée, graduée par niveau de preuve, construite pour l'examen des régulateurs, des acquéreurs, des assureurs et des clients grands comptes.
Un code écrit par un modèle et revu par le même modèle n'a été revu par personne.
Personne n'achète une revue de code. On achète ce qu'elle débloque.
Vous ne lisez pas ceci parce que vous vous êtes réveillé en voulant une évaluation de sécurité. Quelque chose vous demande des preuves.
Trois de ces quatre n'acceptent jamais votre parole sur votre propre code — l'indépendance est la propriété qu'ils achètent, et c'est la seule propriété qu'aucune équipe ne peut fournir sur son propre travail. Le quatrième, le régulateur, acceptera souvent votre auto-évaluation — puis vous tiendra à chaque dossier qui la fonde. Dans les deux cas, la preuve doit tenir. C'est ce que nous produisons.
Le livrable est le but.
Un engagement produit une CounterProof Assessment sous un identifiant d'engagement persistant (CPR-YYYY-NNN — ce que citent vos mainteneurs, votre acquéreur ou vos commits de correction). Chaque constat est soit confirmé contre votre source — fichier et ligne exacts, chemin de reproduction, classification d'impact — soit explicitement gradué comme plausible seulement. Rien de rembourré, rien de généré par scanner, rien sur quoi vous ne puissiez pas agir.
Chaque constat nomme l'échelon de preuve qu'il a réellement atteint — trace dans la source, preuve de compilation, test, ou reproduction en exécution — et n'en laisse jamais entendre un plus élevé. Chaque citation chemin:ligne est résolue mécaniquement contre la révision exacte que nous avons examinée avant que le rapport ne quitte nos mains. Vous pouvez vérifier notre travail. C'est délibéré.
Le marché s'est mis à rivaliser sur le nombre de constats qu'un outil peut générer — mais un constat est un témoin, pas un verdict, et l'étiquette de gravité qui fait le gros titre est le seul champ que personne ne peut vérifier. Un constat n'est pas un verdict →
La fluidité n'est pas un signe de qualité. C'est le mode de défaillance.
Quand une personne écrit une ligne de code, elle en doute. Elle sait qu'elle devinait — et ce doute est un dispositif de sécurité, car c'est lui qui la pousse à aller tester la chose.
Un modèle écrit la même ligne avec fluidité, précisément de la voix qu'il emploie pour les lignes qui sont correctes. Pour la personne qui lit, la fluidité se lit comme de la compétence. Un ingénieur junior vous tend quelque chose de visiblement brut et vous le vérifiez. Un modèle vous tend deux cents lignes polies avec une raison assurée pour chacune, et vous ne le faites pas.
Le piège n'est pas que les modèles se trompent plus souvent que les gens. C'est que leurs mauvaises réponses arrivent avec la même voix que les bonnes — indistinguables de l'extérieur, parce qu'elles sont indistinguables de l'intérieur.
Puis le même processus écrit le test qui certifie le code, et le commentaire qui l'explique. Les trois concordent, parce que les trois viennent du même endroit. Cette concordance se lit comme trois confirmations indépendantes. C'en est une.
La question utile n'est donc pas de savoir si un modèle peut écrire du bon code — il le peut, avec une méthode autour. C'est de savoir ce que votre processus de revue mesure réellement quand tout ce qu'il inspecte vient de la même source : le code, le test, l'explication, et de plus en plus l'outil que vous avez construit pour les vérifier. Bien fait, le résultat est bon. Mal fait, il se lit exactement pareil.
Une revue trouve ce que son relecteur peut trouver.
Faites passer un modèle sur une base de code et un court rapport vous dit quelque chose d'étroit : ce modèle, dans ce harnais, ce jour-là, a fait remonter ceci. Ce qu'il n'a pas fait remonter n'est pas dans le rapport, et par construction ne peut pas y être.
L'importance de cela dépend du degré de recouvrement des angles morts des différents relecteurs — ce que, pour la revue de code, personne n'a mesuré. La recherche sur les erreurs corrélées entre fournisseurs a trouvé un recouvrement substantiel sur des bancs d'essai à choix multiples et sur une tâche de tri de CV ; que cela se transpose à la découverte de vulnérabilités n'est pas établi. Ce que cela montre, en revanche : des fournisseurs différents ne sont pas automatiquement indépendants les uns des autres.
Plusieurs choses peuvent borner ce qu'une passe unique a manqué : une preuve, une suite de tests, un fuzzer, un spécialiste, des défauts semés, ou un relecteur différent du premier. Ce qui ne peut pas le borner : relire la même passe avec plus de confiance.
Nous n'avons pas démontré que la revue multi-relecteurs attrape davantage de défauts réels — l'expérience que nous avions conçue pour le tester a été retirée avant d'être menée, et nous le disons publiquement. Le point plus étroit est celui que nous défendons : une passe propre d'un relecteur est un résultat délimité, et le lire comme un certificat de propreté est une inférence que ce résultat ne soutient pas. L'argument complet (en anglais) →
Nous avons couché l'argument long par écrit, y compris là où se trouvent les limites de notre propre méthode et ce que nous n'avons pas démontré : une introduction en langage clair, et le papier complet derrière elle, publié en prépublication sous doi:10.5281/zenodo.22030516 (CC BY 4.0), en anglais. Il n'est pas relu par des pairs, et il le dit.
Vous pourriez faire tourner les mêmes modèles. Vous ne pouvez pas être indépendants.
Faire passer plusieurs modèles d'IA sur votre propre code réplique notre outillage et perd la propriété qui compte. Votre équipe choisit ce que voient les relecteurs, cadre les questions et juge les réponses — et chacun de ces choix ramène vos hypothèses tout droit dans la revue. Ce n'est pas un défaut de discipline ; c'est structurel. L'auteur d'un système ne peut pas en être l'arbitre.
Même une revue interne irréprochable reste donc votre parole sur votre propre code. Ce qu'ils achètent, c'est un tiers prêt à signer. Nous ne sommes pas un organisme notifié et nous ne certifions pas la conformité ; nous produisons la preuve indépendante qui soutient votre évaluation et qui est structurée pour être réexaminée par celle de n'importe qui d'autre.
La méthode se moque de qui — ou de quoi — a écrit votre code. L'indépendance manque tout aussi souvent au code écrit par des humains. Le code écrit par des machines rend seulement l'écart impossible à ignorer.
Vous le découvririez de toute façon. Mieux vaut l'entendre de nous.
CounterProof fait partie d'un groupe qui construit des infrastructures de paiement et de conservation d'actifs numériques. C'est là que cette méthode a été forgée — et cela signifie que si vous construisez sur ces marchés, notre affilié peut être adjacent à vous, ou en concurrence avec vous.
Donc : avant tout engagement, nous vous disons exactement ce que le groupe construit et où il opère, par écrit. Vous décidez si c'est acceptable, et vous le décidez avant de nous avoir payé quoi que ce soit. Si ce n'est pas acceptable, c'est une réponse légitime et nous préférons l'entendre au départ.
Ce que notre revendication d'indépendance couvre et ne couvre pas, précisément : nous n'émettons pas d'évaluation sur du code écrit par CounterProof ou par une société de notre groupe. Cette frontière est structurelle. C'est une affirmation sur le code de qui nous examinons, pas la prétention de n'avoir aucun intérêt commercial nulle part près de votre secteur — aucun cabinet de revue doté d'une vraie expertise de domaine ne peut honnêtement prétendre cela, et nous n'allons pas faire semblant.
Trois personnes, nommées, au dossier.
Une évaluation signée signifie que le nom de quelqu'un est dessus. Voici les personnes — et quel nom porte quoi.
Nous sommes une pratique familiale — père, fils et fille — et le banc de revue compte deux personnes. Ce sont deux faits qu'une équipe de due diligence découvre par elle-même, alors nous préférons les dire ici : un banc de deux relecteurs prend moins d'engagements qu'un cabinet, décline tout ce qui sort de son domaine, et ne peut pas cacher une passe faible derrière une marque. C'est l'échange, et c'est la raison pour laquelle la méthode est écrite et mécanisée plutôt que portée dans la tête de quelqu'un.
Ce que nous lisons, et ce que nous vérifions.
Trois études indépendantes, trois méthodes différentes — une étude ciblée de vulnérabilités, une comparaison contrôlée humain-modèle et un an d'observation de dépôts réels — convergent vers le même constat : le code généré par IA porte un coût de qualité mesurable qui survit au gain de productivité avec lequel il est arrivé.
L'IA peut désormais générer des milliers de constats de vulnérabilité en un après-midi. Un constat est un témoin, pas un verdict — et le seul champ que personne ne peut vérifier est celui que tout le monde gonfle. Voici comment lire le flot sans s'y noyer.
L'IA a fait s'effondrer le coût de la découverte de vulnérabilités. Dans l'écosystème open source de Bitcoin, cette collision est arrivée ce mois-ci — et Bruxelles a mis un chronomètre sur la suite.
Parlez-nous avant que l'échéance ne le fasse.
Les demandes d'information vont à Elenora Soons, account manager :