Comment nous calculons

Gain d’information

Un lecteur aborde un texte avec des questions : que faut-il faire exactement, où, quand, combien, dans quelles conditions et pourquoi. Le gain d’information est la part de ces questions auxquelles le texte répond. À 100 %, le lecteur n’a plus rien à demander ; un formulaire aux champs vides est proche de 0 %. Le modèle de votre navigateur estime cette part sous forme de note de 0 à 10 et l’affiche par paliers de 5 %.

L’idée remonte à Claude Shannon, qui mesurait l’information en bits : un bit est la réponse à une question fermée, du type oui ou non (Shannon, 1948). Un rapport de bug qui dit « les gros exports échouent » laisse le développeur demander « à partir de 12 300 lignes, ou de 11 000 », une question fermée après l’autre ; « les exports de plus de 10 000 lignes échouent » répond à toutes d’un coup. Warren Weaver a décrit trois niveaux de communication : si les symboles arrivent, s’ils portent le sens voulu et s’ils changent ce que fait le destinataire (Weaver, 1949) ; Slopcheck travaille aux deuxième et troisième niveaux.

Le gain d’information en SEO

En SEO, le gain d’information (en anglais “information gain”) désigne ce qu’une page apporte au-delà des pages que son lecteur a déjà vues. Google détient un brevet sur un tel score, “Contextual estimation of link information gain” (US 11,354,342 B2, délivré le 7 juin 2022). Un brevet ne prouve pas qu’un score sert au classement ; les consignes publiques de Google demandent si le contenu apporte « des informations, des reportages, des recherches ou des analyses originaux » (en anglais : “original information, reporting, research, or analysis”, Google Search Central). Slopcheck mesure ce que montre un seul texte, sans le comparer à d’autres pages : la part des questions de son lecteur auxquelles il répond, de 0 à 100 %.

Ce qu’un énoncé exclut

Rudolf Carnap et Yehoshua Bar-Hillel ont décrit le versant sémantique de l’information : un énoncé porte d’autant plus d’information qu’il exclut d’états possibles du monde (Carnap et Bar-Hillel, 1952). « L’export échoue pour les commandes de plus de 500 lignes dans Chrome 128 » exclut bien plus que « l’export échoue parfois ». Un seuil nommé est la forme la plus forte : « 3.1.4 fonctionne, 3.2.0 échoue » indique au développeur quelle version ouvrir.

La vérité d’un énoncé est une autre question (Stanford Encyclopedia of Philosophy). Slopcheck ne vérifie pas les faits : « commandes de plus de 500 lignes » obtient le même score, que le vrai seuil soit 500 ou 5 000.

Ce qui compte pour le lecteur

Ronald Howard a montré en 1966 qu’une information vaut ce qu’elle change dans une décision (Howard, 1966). Pour un développeur, « Chrome 128 » décide lequel des 3 navigateurs tester ; « l’export est important » ne décide rien. Sur une fiche produit, « 4 EUR par utilisateur et par mois, 30 premiers jours gratuits » change la décision d’achat ; « une expérience fluide » ne la change pas. Dans un rapport de bug, la version, les étapes et le seuil changent la prochaine action du développeur.

Slop

Le slop est la part du texte, comptée en mots, qui ne répond à aucune question du lecteur. Nous en distinguons 4 types : les phrases vides, qui iraient dans n’importe quel texte ; les évidences, qui n’excluent aucune possibilité envisagée par le lecteur ; les hors-sujet, qui ne changent aucune décision ; et les renvois impossibles à résoudre, tels que « comme convenu » ou « idem que là-bas ». Les répétitions d’informations déjà données comptent aussi. Dans le résultat, chaque phrase de slop est surlignée.

Sur le plan conversationnel, le slop enfreint 2 des maximes décrites par Paul Grice : être aussi informatif que nécessaire, sans plus, et rester pertinent (Grice, 1975). Les répétitions correspondent à la redondance de Shannon : la partie d’un message que le lecteur peut prédire à partir du reste.

Le style n’est pas du slop : « nous avons corrigé l’export CSV » et « le problème d’export CSV a été résolu » comptent de la même façon.

Le lien entre les deux chiffres

Le slop ne porte aucune information : plus un texte contient de slop, plus le plafond de son gain est bas. Un texte composé à 60 % de slop obtient au plus environ 50 %, et un texte à 95 % de slop ou plus obtient au plus 10 %. Un score de 100 % ne s’affiche que si aucune phrase n’est du slop ; sinon, le gain plafonne à 95 %. La longueur n’est pas le but : un rapport de bug de 50 mots peut obtenir 90 %.

Rapports de bug, tâches et fiches produit

Nous avons recensé 27 questions qu’un lecteur pose à un texte : 7 pour tout texte, 8 pour les rapports de bug, 7 pour les tâches et 5 pour les fiches produit. Un rapport de bug répond à : quelle version, quelles étapes, quel comportement attendu et quel comportement observé, toujours ou parfois, et depuis quelle release. Une tâche ou une user story répond à : quoi, où, pourquoi, comment vérifier qu’elle est terminée et à quoi ne pas toucher. De bons critères d’acceptation se lisent par exemple ainsi : « 34 paramètres, 4 onglets, aucun changement de texte ». Une fiche produit bien rédigée indique le public visé, la fonction du produit, les preuves, le prix et l’étape suivante. Le modèle a appris les différences entre types de textes sur 2 424 exemples notés par un modèle de langage : vous n’avez donc pas à choisir un type avant de coller un texte.

5 versions en 4 jours

La version 1, le 19 octobre 2026, comptait les mots outils, les mots de remplissage et les détails concrets pour 100 mots. La version 2 ajoutait la rareté des mots, mesurée sur des listes de fréquences que nous avons calculées à partir d’environ 600 000 mots de Wikipédia par langue ; sur 55 pages web notées par deux modèles de langage, c’était du bruit (AUROC de 0,45 à 0,49), et nous l’avons abandonnée. La version 3 jugeait d’après le nombre de détails concrets pour 100 mots ; sur 37 nouvelles pages mises de côté pour les tests, son verdict « trop peu de substance » n’était juste que dans 1 cas sur 9, et il est devenu un simple indice.

La version 4 utilisait un catalogue d’environ 1 000 motifs dans 5 langues et séparait les pages délayées des pages denses sur les mêmes 37 pages (AUROC de 0,75 ; nous avions vu ces résultats pendant le développement, le chiffre est donc optimiste). Sur de vrais rapports de bug, elle ne faisait pas mieux que le hasard (0,47 à 0,52). Cet échec nous a fait passer du comptage des mots au comptage des questions ouvertes du lecteur, puis à la version 5 (s2) le 22 octobre ; le 24 octobre, nous l’avons réentraînée pour 12 langues (s3).

Ce que les outils de suivi des bugs nous ont appris

Nous avons étudié 1 355 rapports Mozilla Bugzilla de 2023 à 2025. Les rapports clos comme incomplets ou en “works for me”, ou dont l’auteur avait été prié de fournir plus d’informations, étaient plus longs que les rapports corrigés sans une telle demande (médiane de 165 mots contre 124) et plus concrets : les personnes extérieures remplissent le gabarit complet, présent dans 38 % des rapports “works for me” et dans 14 % des rapports corrigés, tandis que les ingénieurs écrivent des notes courtes qui s’appuient sur un contexte partagé. L’issue mesurait donc qui avait écrit le rapport : dès lors, nous avons comparé des rapports d’un même auteur.

Sur Apache Jira, nous avons collecté 11 129 rapports de bug de 165 projets, déposés depuis 2022, et comparé les rapports corrigés à ceux clos en “Cannot Reproduce” ou “Incomplete”. Un constat a façonné la méthode : un modèle de langage a lu 240 de ces rapports, soit 120 paires d’un même auteur, sans connaître l’issue ni l’auteur. Interrogé sur la présence d’une version ou d’un environnement, il en trouvait plus souvent dans les rapports mal reçus (63 % contre 50 %). Interrogé sur ce dont un développeur aurait encore besoin, il citait plus souvent la version ou l’environnement pour ces mêmes rapports (48 % contre 33 %) : mentionner un détail ne revient pas à répondre à la question.

Les règles d’une revue manuelle

Nous avons noté 35 textes à la main, la plupart sur une échelle de 0 à 10 : 0 correspond à un formulaire vide, 5 à 6 à un travail faisable après quelques questions, 9 laisse une question ouverte et 10 ne laisse rien à ajouter. Sur 28 de ces textes, notre premier catalogue de questions a soulevé 86 questions ; nous en avons annoté 35, dont 26 jugées justes et 9 excessives. Le résultat est un guide écrit de 37 règles et 33 cas de test.

Exemples de règles : un énoncé sans limite vaut pour toujours et partout, donc une version manquante ne coûte rien, sauf si le texte dit « parfois » ou « après la mise à jour » ; une interdiction ne compte que si elle ferme une piste que la tâche suggère ; les exigences contradictoires coûtent le plus cher. Dans un test, les mêmes faits, réécrits avec un lien explicite et un objet nommé, sont passés de 1 à 9–10 sur 10. Dans un autre, un rapport noté 10 à la main avait été clos en “Cannot Reproduce” : l’issue dans l’outil de suivi est un signal, pas un verdict.

Les modèles de langage comme évaluateurs et comme enseignant

Nous avons transformé les 37 règles en guide de notation pour de grands modèles de langage et comparé 5 modèles sur les 27 textes dotés d’une note manuelle chiffrée. Les règles venaient de ces textes : cela montre donc à quel point chaque modèle suit les règles, et non ses résultats sur de nouveaux textes. Les deux meilleurs sont restés à 1 point au plus de la note manuelle pour 22 textes sur 27 (corrélation de rang jusqu’à 0,94) ; le plus faible, pour 12 sur 27.

L’un des deux a ensuite noté 2 424 textes phrase par phrase : 600 tâches et rapports de bug publics d’Apache Jira, 384 textes reprenant les mêmes faits, écrits par des modèles de langage dans 4 styles, 600 textes que le même modèle a écrits pour l’entraînement en allemand, polonais, tchèque, croate et russe, et 840 textes écrits par des modèles de langage qui n’avaient pas vu les règles, à raison de 120 par langue en slovaque, slovène, bulgare, français, italien, espagnol et néerlandais. Cela fait 18 420 phrases annotées, dont 21,4 % de slop. Le petit modèle de votre navigateur a appris à partir de ces annotations. En validation croisée, sa corrélation de rang avec l’enseignant est de 0,85, et sur des textes qu’il n’a pas vus à l’entraînement, il retrouve les phrases de slop de l’enseignant avec une AUROC de 0,92. Sur 25 textes notés à la main, sa corrélation de rang avec les notes manuelles est de 0,81, mais les règles appliquées par-dessus viennent de ces mêmes textes : les tests sur données mises de côté, plus bas, sont donc la mesure la plus juste.

Aucun modèle de langage ne lit votre texte quand vous le vérifiez. Un appel à un modèle enverrait le texte à un tiers, ne donnerait pas toujours la même réponse pour un même texte et coûterait de l’argent à chaque vérification ; le petit modèle tient dans environ 350 Ko de poids fixes.

Des prédictions consignées à l’avance

Pour 5 expériences, nous avons consigné nos prédictions dans un fichier avant de lancer le test ; pour le test des motifs du 20 octobre 2026, la somme de contrôle MD5 du fichier commence par ff01ce1a. Nous avions prédit que la version simple d’un texte battrait la version de style assistant dans 85 % à 95 % des paires : ce fut le cas dans 79 %. Nous avions prédit que les rapports Bugzilla rejetés seraient plus courts : ils étaient plus longs, avec une médiane de 165 mots contre 124. Sur les paires Jira d’un même auteur, 3 prédictions sur 4 ont échoué. Après l’échec sur Bugzilla, chaque comparaison suivante a porté sur des rapports d’un même auteur.

Ce qui n’a pas fonctionné

La rareté des mots (AUROC de 0,45 à 0,49). La part des mots outils et des mots de remplissage, qui n’atteignait sur les pages mises de côté qu’une AUROC de 0,31, pire que le hasard. Un verdict « trop peu de substance » juste 1 fois sur 9. Le comptage d’unités de sens ou une grille de complétude en 5 points, dont la corrélation de rang avec une lecture du texte entier n’était que de 0,18 à 0,26. 8 indicateurs calqués sur les signaux des moteurs de recherche, rejetés dès la conception. La comparaison d’une page avec les 3 à 10 premiers résultats de recherche, qui exige une API de recherche payante. Des versions larges des règles explicites, qui se déclenchaient sur 33 rapports Jira ; chacun de ceux que nous avons vérifiés était une fausse alerte. Un modèle de langage au moment de la vérification : c’est lui qui s’approchait le plus des notes manuelles, mais il enverrait votre texte à un tiers.

Comment nous testons la méthode

Nous mettons de côté 24 briefs en anglais et en allemand, chacun écrit en 4 versions par des modèles de langage. La version simple obtient un score plus élevé que la version délayée dans les 24 paires, et plus élevé que la version de style assistant dans 83 % des cas. Pour chacune des 7 langues ajoutées le 24 octobre, nous mettons de côté 6 briefs de plus en 4 versions : la version simple bat la version délayée dans chaque paire, et la version de style assistant dans 100 % des paires en slovaque et en slovène, 92 % en italien et en néerlandais, 83 % en bulgare et en français et 58 % en espagnol.

Sur 120 paires mises de côté de rapports Jira d’un même auteur, le rapport corrigé obtient un score plus élevé dans environ 60 % des paires. Un modèle de langage qui lit les mêmes 240 rapports à l’aveugle, sans l’issue ni l’auteur, atteint 64 %. Les briefs anglais et allemands et les paires Jira ont été exclus de l’entraînement, mais nous les avons utilisés pour choisir entre des variantes des règles explicites : sur de nouveaux textes, les résultats peuvent donc être un peu plus bas. Qu’un rapport finisse corrigé ou clos en “Cannot Reproduce” dépend aussi du bug lui-même : il peut être déjà corrigé dans une version plus récente, ne survenir que dans un seul environnement ou venir d’une erreur de configuration ; 100 % est donc impossible sur ce test.

Comment l’estimation est calculée

Pour le texte entier, le modèle lit 182 signaux, comme les nombres, les versions, les conditions, les seuils, les noms, les messages cités, les mots vagues, les affirmations non étayées, les répétitions et les intertitres vides d’un gabarit, plus des mots et des paires de mots hachés dans 16 384 cellules ; un second modèle, avec 68 signaux et les mêmes mots hachés, décide pour chaque phrase si elle est du slop. Le modèle de texte est une régression linéaire sur ces signaux et le modèle de phrase une régression logistique, tous deux ajustés sur les 2 424 textes notés. 3 règles issues de la revue manuelle s’appliquent en plus du modèle. Une heure de début postérieure à l’échéance coûte 25 points. Une tâche qui commence par « diviser en 4 onglets » sans jamais dire quoi diviser obtient au plus 20 %. Un gabarit aux intertitres vides obtient au plus 10 %. Les poids occupent environ 350 Ko et se chargent avec la page, et un texte de 3 000 caractères est vérifié en moins de 100 millisecondes.

Phrases et langues

Nous découpons le texte en phrases aux points, aux points d’interrogation et d’exclamation, aux points de suspension et aux sauts de ligne, mais pas à l’intérieur de « v8.1 », de « 1.200 » ou d’une adresse web, ni après une date comme « 7. Juni ». 12 langues sont prises en charge : anglais, polonais, tchèque, slovaque, croate, slovène, bulgare, allemand, français, italien, espagnol et néerlandais. La langue est détectée automatiquement : 99,6 % de réussite sur nos jeux de test précédents et 97,1 % sur les textes courts dans les nouvelles langues. Nous avons compilé nous-mêmes les listes d’expressions de slop pour les 11 langues autres que l’anglais ; pour l’allemand, le polonais, le tchèque et le croate, nous n’en avons trouvé aucune en accès libre. La vérification gratuite accepte de 80 à 3 000 caractères, ce qui couvre 97,5 % des rapports de bug Jira que nous avons collectés, hors blocs de code. Biais connu : la langue seule décale l’estimation de quelques points. À signaux égaux, les textes espagnols, français, tchèques et italiens obtiennent 5 à 8 points de moins que les textes anglais, et les textes allemands et néerlandais environ 4 points de plus : comparez donc les scores au sein d’une même langue.

Ce que nous ne mesurons pas

Slopcheck ne mesure pas qui a écrit un texte, s’il est vrai ni comment il sera classé dans Google ou Bing. Sur un échantillon du benchmark public RAID en anglais, des caractéristiques textuelles fondées sur des règles ont repéré au plus 28 % des textes écrits par IA, pour un taux de fausses alertes de 5 % : c’est pourquoi nous ne proposons pas de détection de l’auteur. Une note de 2 lignes peut être parfaitement juste pour une équipe qui partage son contexte : l’estimation ne voit que le texte.

Questions

Comment vérifier un texte pour y repérer le slop IA ?

Collez-le dans le champ de la page d’accueil : de 80 à 3 000 caractères, jusqu’à 5 textes par jour gratuitement. Vous obtenez le gain d’information, la part de slop et les phrases de slop marquées dans le texte.

Mon texte est-il conservé ou envoyé quelque part ?

Non. La vérification se fait dans votre navigateur : le texte ne nous est pas envoyé et n’est pas conservé. Le lien du résultat garde le texte dans la partie de l’adresse qui suit le signe #, que les navigateurs n’envoient pas aux serveurs.

Quels textes puis-je vérifier ?

Articles, fiches produit, publications, tâches, user stories et rapports de bug en 12 langues : anglais, polonais, tchèque, slovaque, croate, slovène, bulgare, allemand, français, italien, espagnol et néerlandais, de 80 à 3 000 caractères.

Comment rédiger un bon rapport de bug ?

Indiquez comment reproduire le problème : quelles étapes, quelle version, quel appareil et à partir de quel seuil l’échec commence. Dans une étude de 180 rapports de bug Android reproductibles, 92,2 % omettaient au moins 1 étape (Johnson et al., 2022). « L’export échoue pour les commandes de plus de 500 lignes dans Chrome 128 » exclut bien plus que « l’export échoue parfois ». Collez le rapport dans la vérification pour voir quelles phrases ne répondent à aucune de ces questions.

Slopcheck est-il un détecteur d’IA ?

Non. Slopcheck estime ce qu’un texte apprend à son lecteur. Il ne dit pas qui ou quoi l’a écrit : un texte généré avec de vrais faits peut obtenir un score élevé, et un texte écrit à la main sans aucun fait obtient un score faible.

En quoi Slopcheck diffère-t-il des outils qui cherchent les marqueurs de l’IA ?

Les outils qui comptent les tirets cadratins, « delve » ou « tapestry » s’arrêtent à la surface d’un texte. Slopcheck regarde ce que le lecteur obtient : un texte peut éviter tous ces marqueurs et ne répondre pourtant à aucune question du lecteur.

Qu’est-ce qu’un passeport de texte ?

Le relevé d’un texte précis : son empreinte, son gain d’information, son slop, la version de la méthode et la date de la vérification, sur une page qui a son propre lien. Quiconque possède le texte peut l’y coller et voir s’il correspond : si un seul caractère diffère, l’empreinte diffère. Chaque modification est enregistrée comme une nouvelle version avec ses propres scores.

Faut-il un plugin ou un SDK pour utiliser l’API ?

Non. Avec l’offre Équipe, la vérification est une seule requête HTTP avec le texte. Elle s’intègre à une étape de CI, à un hook avant publication dans un CMS ou à un champ de votre outil de suivi des tâches.

Sources

1. C. E. Shannon (1948). A Mathematical Theory of Communication. Bell System Technical Journal
2. C. E. Shannon, W. Weaver (1949). The Mathematical Theory of Communication. University of Illinois Press
3. Google LLC (2022). Contextual estimation of link information gain. Brevet US 11,354,342 B2
4. Google Search Central. Creating helpful, reliable, people-first content
5. R. Carnap, Y. Bar-Hillel (1952). An Outline of a Theory of Semantic Information. MIT Research Laboratory of Electronics
6. S. Sequoiah-Grayson, L. Floridi. Semantic Conceptions of Information. Stanford Encyclopedia of Philosophy
7. R. A. Howard (1966). Information Value Theory. IEEE Transactions on Systems Science and Cybernetics
8. H. P. Grice (1975). Logic and Conversation ; les maximes sont résumées dans « Implicature », Stanford Encyclopedia of Philosophy
9. J. Johnson et al. (2022). An Empirical Investigation into the Reproduction of Bug Reports for Android Apps. SANER 2022, section IV-C
10. Apache Software Foundation. Outil de suivi Jira, rapports de bug et tâches publics 2022–2026
11. Mozilla. Bugzilla, rapports de bug publics 2023–2025
12. L. Dugan et al. (2024). « RAID: A Shared Benchmark for Robust Evaluation of Machine-Generated Text Detectors ». ACL 2024