revue de code adversariale indépendante
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.
Parlez-nous avant que l'échéance ne le fasse →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.
Où se situe la revue dans votre gestion des vulnérabilités, étape par étape →
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. Le dossier consigne aussi ce que nous avons vérifié sans le trouver : un négatif consigné est ici un livrable, pas une mission échouée.
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é.
Quand un constat ne survit pas à l'examen — le vôtre, celui de vos mainteneurs ou notre propre réexamen — nous le rétractons par écrit, avec la raison, sous le même identifiant d'engagement. Nous le faisons sans y être invités ; la contrepartie n'a pas à le demander. Le journal des retraits n'est pas un aveu ; c'est le mécanisme.
Spécimen — la forme d'un constatSpécimen illustratif, ne provenant pas d'une mission client ; les identifiants sont des espaces réservés. Les rapports sont émis en anglais.
« Les témoins sont désormais gratuits. L'édition critique ne l'est pas. »
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. Une citation fichier:ligne, un lecteur peut l'ouvrir et la vérifier en une minute ; un simple « Critique » non. Dans nos dossiers, la gravité est un produit du niveau de preuve, jamais un intrant du marketing. Les témoins sont désormais gratuits. L'édition critique ne l'est pas. Un constat n'est pas un verdict →
Quatre étapes. Vous connaissez le périmètre avant de payer, et vous gardez le dossier après.
Un premier engagement n'a pas à couvrir tout ce que vous livrez. Un périmètre restreint et bien choisi — un module, une frontière de confiance — produit le même dossier défendable, à une taille que vous pouvez évaluer, et il peut être la première pièce de preuve au titre de la partie II, point 3), qu'un fabricant verse au dossier.
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.
« Leurs réponses erronées arrivent avec la même voix que les bonnes. »
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, dans des populations de modèles incluant différents 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. Les nôtres sont nommés ci-dessus, et vous décidez s'ils sont acceptables avant de nous avoir payé quoi que ce soit.
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.
Des modèles d'autres fournisseurs ont contribué à écrire, sélectionner et juger les données d'entraînement de Kolibri-1. Le résumé européen liste sept noms ; le rapport technique explique les différents rôles. Ces divulgations montrent comment un modèle construit pour un déploiement souverain et spécialisé peut s'appuyer sur des modèles d'autres fournisseurs pendant l'entraînement. Elles n'établissent pas quels comportements, s'il y en a, ont été hérités.
Des douze configurations d'agents, celle qui a le plus souvent produit du code fonctionnel l'a fait dans 57 % des tâches ; dans 11,8 % seulement, son code à la fois fonctionnait et réussissait le test de sécurité. Informer l'agent du risque a un peu aidé. L'étude pouvait tester chaque faille parce qu'elle avait déjà été trouvée et corrigée, et que le correctif était accompagné d'un test de sécurité. Le nouveau code de votre agent n'a pas encore de tel test.
Le règlement ne mentionne jamais les portefeuilles crypto. Il s'applique aux produits comportant des éléments numériques. À partir de décembre 2027, il exige aussi de soumettre régulièrement le produit à des tests et examens de sécurité efficaces. Selon notre lecture, cette obligation a une incidence sur la question de savoir si un fabricant trouve une faille avant un attaquant. Cette note explique le champ d'application, les délais de notification et le rôle d'une revue indépendante.
Parlez-nous avant que l'échéance ne le fasse.
Les demandes d'information vont à Elenora Soons, account manager :