Un texte écrit par IA se reconnaît souvent avant même la fin du premier paragraphe : un tiret long tous les deux phrases, une annonce de plan, trois adjectifs là où un seul suffisait. Si vous publiez des articles, des posts ou des pages rédigés avec un modèle, vous vous êtes sans doute demandé si cela se voyait, et s'il fallait passer vos textes dans un détecteur avant de les mettre en ligne.
J'écris ce blog avec une machine de contenu que j'ai construite, et je le dis sans détour. Ce qui m'occupe, c'est qu'ils soient bons, pas d'en masquer l'origine. Voici les signes que je surveille, pourquoi je ne me fie pas aux détecteurs, et les contrôles concrets que mon outil passe avant chaque publication.
01Les signes d'un texte écrit par IA, et pourquoi aucun ne suffit seul
Les signes les plus connus tiennent à la forme. Le tiret cadratin employé partout. Les phrases qui annoncent ce qui va suivre au lieu de le dire. La construction « ce n'est pas X, c'est Y ». Les énumérations systématiques par trois. Les adjectifs d'insistance et les connecteurs de dissertation. Les listes à puces dont chaque ligne commence par un mot en gras suivi de deux-points. Un rythme très régulier, où toutes les phrases ont la même longueur.
Le problème, c'est qu'aucun de ces signes ne prouve quoi que ce soit pris seul. Le guide que tient un groupe de bénévoles de Wikipédia sur les signes d'écriture générée le rappelle dès l'introduction : les modèles ont appris sur des textes humains, et beaucoup de ces tournures se trouvent dans des éditoriaux ou des blogs écrits à la main. Le même guide demande de ne pas traiter ces signes comme le problème à corriger, parce que les vrais défauts sont plus profonds.
Le linguiste Taylor Jones va dans le même sens dans une vidéo que j'ai trouvée utile, How to Detect AI Slop. Les groupes de trois et les incises, dit-il, relèvent de la rhétorique classique ; ensemble, ils sont évocateurs, isolés, ils ne disent rien. Le signe qu'il juge le plus fiable est ailleurs : des mots qui vont bien ensemble mais ne veulent rien dire une fois réunis, des métaphores qui se contredisent dans la même phrase. Je le retrouve souvent dans les premiers jets que je relis : une phrase qui sonne bien et qui ne résiste pas à une lecture lente.
02Pourquoi je ne me fie pas aux détecteurs
La tentation est compréhensible : coller le texte dans un outil, lire un pourcentage, décider. Je ne le fais pas, et les éditeurs de modèles eux-mêmes donnent de bonnes raisons de s'en méfier.
OpenAI a publié en janvier 2023 un classifieur censé repérer les textes écrits par IA. Sur son jeu de test, il identifiait 26 % des textes générés comme « probablement IA », et il étiquetait à tort 9 % des textes humains. La page précise qu'il était très peu fiable sous 1 000 caractères, nettement moins bon dans les autres langues que l'anglais, et qu'un texte retouché pouvait lui échapper. OpenAI l'a retiré le 20 juillet 2023, pour faible précision.
La recherche publiée va dans le même sens. Une équipe de chercheurs a montré que plusieurs détecteurs courants classent à tort comme générés les textes de personnes dont l'anglais n'est pas la langue maternelle, et qu'une simple consigne donnée au modèle suffit à les contourner. Une autre équipe a testé une paraphrase répétée sur une large gamme de détecteurs, y compris ceux qui reposent sur un filigrane : les taux de détection chutent, alors que la qualité du texte baisse peu.
J'en tire une règle simple. Un détecteur peut servir d'alerte, jamais de verdict. Et pour vos propres textes, il pose la mauvaise question : savoir si un texte « passe » ne dit pas s'il est juste, utile ou sourcé.
03Ce que Google regarde : la qualité, pas l'origine
Beaucoup de personnes qui me posent la question pensent surtout au référencement. La réponse officielle est claire. Dans ses conseils sur le contenu généré par IA, Google Search Central écrit se concentrer sur la qualité du contenu plutôt que sur la façon dont il est produit. Ce qui enfreint ses règles, c'est l'automatisation utilisée d'abord pour manipuler le classement.
La même page conseille d'indiquer l'auteur là où le lecteur s'y attend, et de mentionner l'usage de l'IA quand quelqu'un pourrait se demander comment le contenu a été fait. C'est ce que je fais : mes articles sont signés, et je dis comment ils sont écrits. J'en parle plus longuement dans ma machine de contenu avec relecture humaine.
Pour vos textes, la question utile est donc de savoir s'ils valent la peine d'être lus. Savoir s'ils ont l'air humains vient après.
04Les contrôles que je passe avant de publier
Plutôt que de détecter l'IA après coup, j'ai choisi de bloquer ses tics avant publication. Chaque article de ce blog passe par une commande qui relit le texte final et rend un verdict rouge, orange ou vert. Un seul rouge bloque la mise en ligne. Les règles vivent dans un fichier de configuration lu par l'outil, pas dans le prompt : une règle rappelée dans un prompt s'oublie, une règle dans la config bloque.
Une liste rouge et une liste orange
La liste rouge contient ce qui ne passe jamais : le tiret cadratin, les annonces de plan, les invitations à « ne pas hésiter », les formules qui préviennent qu'une chose importante va être dite, quelques mots de consultant. Un seul de ces motifs rend le gate rouge.
La liste orange contient une vingtaine de mots à éviter, adjectifs d'insistance et connecteurs de dissertation surtout. Un orange isolé passe, à condition que je le justifie par écrit. Au-delà de deux occurrences cumulées dans l'article, c'est rouge. Ce seuil compte plus que la liste elle-même : il laisse passer un mot juste et arrête l'accumulation, qui est ce qui trahit un texte généré.
Des compteurs de voix
Le même contrôle compte les marques de première personne, élisions comprises : moins de 4, rouge ; moins de 10, orange. Moins de 5 « vous », orange. Il cherche aussi un passage ancré dans la pratique. Un texte impersonnel ressemble à toutes les pages déjà indexées, et c'est souvent le premier défaut d'un premier jet généré.
Des règles de forme
Les paragraphes ne dépassent pas 110 mots, la moyenne ne dépasse pas 24 mots par phrase. Trois puces ou plus au format « mot en gras, deux-points, texte » donnent un rouge. Les titres gardent une majuscule au premier mot seulement. Chacune de ces règles correspond à un défaut que j'ai vu revenir en production.
Des articles de test qui doivent rester rouges
Quand je modifie une règle, je peux affaiblir le contrôle sans m'en rendre compte. J'ai donc des articles de test volontairement mauvais, qui concentrent tous les tics d'un texte généré. Une commande les rejoue : si l'un d'eux sort vert, le test échoue.
05Rendre un texte IA naturel sans le maquiller
Le contrôle retire les tics, mais il ne donne rien à dire au texte. Pour ça, je compte sur deux étapes, l'une avant la rédaction, l'autre après.
Avant : le brief. Je ne laisse pas un modèle écrire tant qu'il n'a pas un angle, des sources lues une à une et des questions réellement posées par des lecteurs. L'angle ne peut s'appuyer que sur une liste fermée de faits publiés sur mon travail. C'est ce qui donne au texte quelque chose à dire. J'ai détaillé ce que le modèle reçoit dans mon prompt de rédaction, couche par couche, et la façon dont je vérifie chaque source avant publication.
Après : une passe de réécriture dédiée, avec un skill qui reprend les signes du guide de Wikipédia. Concrètement, voici ce que je cherche à la relecture :
- Une phrase qui annonce au lieu de dire : je la supprime et je garde la suivante.
- Une construction « ce n'est pas X, c'est Y » : je dis Y, simplement.
- Une énumération par trois sans raison : je garde les éléments qui comptent, parfois un seul.
- Un verbe compliqué à la place de « est » ou « a » : je reviens au verbe simple.
- Une phrase qui sonne bien : je la relis lentement et je vérifie qu'elle veut dire quelque chose.
- Une affirmation sans exemple ni source : j'en ajoute un, ou je la retire.
Les deux derniers points sont ceux que Taylor Jones désigne comme les plus parlants, et ce sont aussi les plus longs à corriger. Ils demandent de savoir de quoi on parle.
06Les limites de cette méthode
Le guide de Wikipédia a raison sur un point qui me concerne directement : traiter les signes comme le problème peut juste rendre la détection plus difficile. Un texte creux, nettoyé de ses tics, reste creux. Mon contrôle le rend seulement moins visible. C'est pour cette raison que le brief bloque la rédaction en amont, et que le contrôle seul ne suffirait pas.
Les listes sont aussi un jugement. Certains mots de la liste orange sont parfois les bons, et je dois alors justifier leur présence. Inversement, un modèle produit de nouveaux tics que mes listes ne connaissent pas encore. Sur une mission, les retours d'une correctrice sont devenus des règles écrites dans le pipeline ; c'est le seul moyen que j'ai trouvé pour que la liste suive.
Enfin, tout cela demande une relecture humaine. Chaque article part en ligne avec le statut « à relire », et je le relis sur le site avant de le passer à « Relu ». J'ai décrit cette étape dans le travail du relecteur, passe par passe.
07Par où commencer avec vos propres textes
Lundi, prenez les trois derniers textes que vous avez publiés avec l'aide d'un modèle. Relisez-les lentement, phrase par phrase, en cherchant ce qui ne veut rien dire et ce qui n'a ni exemple ni source. Notez les formules qui reviennent d'un texte à l'autre.
Cette liste, c'est le début de vos propres règles. Écrivez-la, donnez-la au modèle avant qu'il écrive, et vérifiez qu'elle est respectée après. Le jour où vous la relisez sans y penser, vous pouvez l'automatiser.
Si vous voulez mettre en place ce type de contrôle sur votre propre production, je le construis en mission courte, et mes services décrivent comment je travaille. On peut en parler.