Kyle Kingsbury : l’IA rend le sérieux d’un logiciel facile à imiter

Une documentation claire, complète, bien rédigée : longtemps, c’était un bon signe qu’un logiciel était entretenu par des gens sérieux. Kyle Kingsbury, cité par le blogueur Simon Willison, avertit que ce signe ne vaut plus grand-chose, parce que les IA savent le fabriquer. La question qu’il pose est simple et dérangeante : à quoi reconnaît-on encore un outil digne de confiance ?

Ce que dit Kyle Kingsbury

Le 1er novembre 2026, Simon Willison a publié sur son blog un extrait d’un texte de Kyle Kingsbury. Le passage vient d’un document intitulé « Jepsen results for ParticleDB 1.1.4 », c’est-à-dire des résultats de tests Jepsen sur la version 1.1.4 d’un logiciel nommé ParticleDB. L’extrait cité ne détaille pas ces résultats. Il porte sur une idée plus large.

Voici l’essentiel, traduit : l’usage des LLM érode la confiance dans la documentation, dans les logiciels et dans les organisations qui les produisent. Un LLM (de l’anglais « large language model », grand modèle de langage) est une IA qui génère du texte, comme ChatGPT. Kingsbury ajoute que les ingénieurs se mettront peut-être à traiter tout nouveau projet avec suspicion. Sa raison : les signaux qui servaient à repérer un système mature sont désormais plus faciles à contrefaire.

En clair : ce qui servait de preuve de sérieux peut maintenant être produit en quelques minutes, sans que le sérieux soit au rendez-vous.

Pourquoi une belle documentation rassurait

Ce qui est en jeu pour vous : la plupart des gens choisissent un outil sans pouvoir l’examiner de l’intérieur. Ils se fient donc à des indices visibles.

La documentation est l’un de ces indices. C’est le mode d’emploi d’un logiciel : ce qu’il fait, comment l’installer, ce qu’il ne sait pas faire. Rédiger un bon mode d’emploi demande du temps et une vraie connaissance du produit. Un projet qui en proposait un soigné donnait l’impression d’une équipe investie, qui avait pris la peine d’expliquer son travail.

C’est une règle de bon sens, pas une garantie. Mais elle fonctionnait parce que l’effort était coûteux. Quand un effort devient presque gratuit, il cesse de prouver quoi que ce soit. Un texte de qualité peut désormais sortir d’un modèle de langage sans que personne n’ait vérifié que chaque phrase est exacte.

C’est le sens de la formule de Kingsbury sur les signaux de maturité « plus faciles à contrefaire ». Il ne dit pas que toute documentation écrite avec une IA est fausse. Il dit que son aspect ne permet plus de deviner si quelqu’un a vérifié ce qu’elle raconte.

La question laissée aux mainteneurs

Les mainteneurs sont les personnes qui entretiennent un logiciel : elles corrigent les erreurs, publient les nouvelles versions et tiennent la documentation à jour. Kingsbury leur adresse deux questions. Que peuvent-elles faire, à l’ère des LLM, pour garantir un logiciel correct et une documentation exacte ? Et, ce travail accompli, comment en démontrer la qualité aux utilisateurs ?

La seconde question est la plus difficile. Faire le travail correctement ne suffit plus : il faut pouvoir le prouver à des gens qui ne peuvent pas le constater eux-mêmes, alors que les apparences de la qualité sont à la portée de tous. L’extrait publié par Simon Willison ne donne pas de réponse. Il pose le problème et s’arrête là.

On peut y voir une inversion de la charge de la preuve. Auparavant, un projet à l’air mûr bénéficiait d’une présomption de confiance. Si la suspicion devient la règle pour tout nouveau projet, comme Kingsbury l’envisage, c’est aux auteurs de montrer ce qui distingue leur travail d’une imitation soignée.

Ce que cela change pour un indépendant ou une PME

Ce qui est en jeu : un logiciel mal vérifié peut coûter cher. Une erreur dans un outil de facturation, de gestion de données ou d’automatisation retombe sur celui qui l’utilise, pas sur celui qui l’a écrit.

Le texte de Kingsbury parle d’ingénieurs, pas de dirigeants de petites entreprises. Mais le raisonnement s’étend à tout acheteur : si l’apparence du sérieux ne coûte presque plus rien, elle ne peut plus servir seule de critère. Un site propre, une page d’aide fournie et un ton assuré ne disent plus si le logiciel fait ce qu’il promet.

Précision utile : la source ne propose ni méthode ni liste de contrôle. Ce qui suit relève de la réflexion de TokenDose, pas de Kingsbury. Voici des questions simples à se poser avant d’adopter un outil :

• Qui vérifie ce qui est affirmé ? Y a-t-il un test, un audit ou un retour d’utilisateurs que l’on peut consulter, en dehors de ce que dit le projet sur lui-même ?
• Le projet dit-il ce que son outil ne sait pas faire ? Une documentation qui n’avoue aucune limite mérite plus de prudence qu’une documentation qui en nomme.
• Peut-on essayer sur un cas réel et sans risque, avec des données sans importance, avant de s’engager ?
• Qui est derrière l’outil, et depuis combien de temps ? Une équipe identifiable et une histoire vérifiable pèsent plus qu’une belle vitrine.

Aucune de ces questions ne garantit la fiabilité. Elles déplacent simplement le regard de ce que le projet montre vers ce que l’on peut contrôler soi-même.

Ce qui reste ouvert

Le constat de Kingsbury a des limites, et il vaut mieux les dire. Il s’agit d’un extrait court, d’un avis d’expert, pas d’une étude mesurant combien de documentations sont désormais écrites par des IA ni combien contiennent des erreurs. Il exprime aussi une hypothèse : les ingénieurs « commenceront peut-être » à se méfier. Ce n’est pas encore un fait établi.

Une autre question demeure : comment un mainteneur prouve-t-il qu’un travail a été fait avec soin, quand le texte, lui, n’en dit rien ? À chacun de regarder, la prochaine fois qu’il lit un mode d’emploi impeccable, ce qui permet réellement de vérifier qu’il dit vrai.

Sources

• A quote from Kyle Kingsbury (Simon Willison)