Écrire avec un LLM sans déléguer sa pensée
Un billet relayé par Simon Willison met le doigt sur un problème très concret pour les équipes d’ingénierie : un texte réécrit par un modèle de langage n’est jamais neutre. La règle proposée par Sophie Alpert est simple, mais sévère : si vous signez un document, vous devez pouvoir défendre chaque idée et chaque phrase.
Fil « Politiques internes d’usage de l’IA pour écrire »
Simon Willison a signalé le 11 août 2026 un texte de Sophie Alpert publié le 25 juin 2026 sur une politique interne d’usage de l’IA pour l’écriture par les ingénieurs. Son idée centrale tient en une formule : il n’existe pas de transformation “sans perte” d’un texte en langue naturelle, c’est-à-dire qu’une reformulation change toujours au moins un peu le sens, l’accent ou l’intention du message. (simonwillison.net)
La règle qui change la pratique
La consigne la plus utile pour une équipe est probablement celle-ci : l’auteur doit pouvoir assumer chaque idée et chaque phrase de ce qu’il publie. Alpert écrit qu’il n’est pas acceptable de répondre à un relecteur qu’une formulation étrange vient de l’IA et qu’il faut l’ignorer ; selon elle, cela fait perdre du temps aux lecteurs et brouille la pensée réelle de l’auteur. Elle autorise l’usage d’outils d’IA pour le brainstorming (remue-méninges), le drafting (premier jet) et la proofreading (relecture/correction), mais à condition que le document final reflète réellement la pensée de la personne qui le partage. (sophiebits.com)
Pourquoi c’est important pour les docs d’ingénierie
Le point le plus fort du texte est que “écrire, c’est penser”. Alpert explique que le travail de rédaction — choisir la structure, décider quoi mettre en avant, formuler précisément — améliore la compréhension du sujet par l’auteur lui-même. Elle cite explicitement des artefacts d’équipe comme les tech specs (spécifications techniques), les project status updates (points d’avancement) et les incident retrospectives (retours d’incident) comme des documents qui servent aussi de preuve de réflexion, pas seulement de livrable textuel. Si l’IA permet de sauter cette étape, le risque n’est pas seulement un texte médiocre : c’est une compréhension plus faible du problème. (sophiebits.com)
Ce que cela change concrètement dans une équipe
La politique proposée pousse vers des règles simples et opérationnelles :
- ne pas envoyer un document généré à partir d’un prompt court (instruction brève) sans relecture de fond ;
- privilégier des textes plus courts, car Alpert insiste sur le fait que plus long n’est pas mieux ;
- considérer le temps de lecture comme un coût d’équipe, puisqu’un document écrit une fois est lu par plusieurs personnes ;
- marquer explicitement les passages ou idées repris tels quels d’une IA si on veut les partager comme matériau brut. (sophiebits.com)
Pour un développeur, cela se traduit bien dans un workflow (enchaînement de travail) très concret :
# Mauvais réflexe
llm "Rédige une spec complète pour ce projet" > spec.md
# Meilleur réflexe
llm "Liste 5 angles morts possibles de cette spec"
# puis rédaction humaine de la spec
# puis relecture assistée : clarté, répétitions, fautes
Cet exemple ne vient pas des articles eux-mêmes ; c’est une mise en pratique fidèle de la règle d’Alpert : utiliser le modèle pour explorer, relire ou challenger (mettre à l’épreuve), pas pour signer à votre place. Le message de fond est sobre, mais utile dans le contexte actuel des assistants de code et des agents : pour le code, un test peut parfois trancher ; pour un document, la perte de sens est souvent plus discrète, donc plus dangereuse. (sophiebits.com)