Travail bâclé par l’IA : le repérer et le corriger

Le gain visible n'est pas toujours le gain collectif

Quand une IA rédige un courriel, une synthèse ou une mise à jour de projet, le temps économisé est facile à voir du côté de la personne qui écrit. Le temps du destinataire, lui, est souvent invisible : il n'apparaît ni dans l'outil utilisé, ni dans le décompte de la tâche initiale.

C'est là que se joue la valeur réelle du transfert. Si le destinataire doit vérifier les chiffres, retrouver les documents cités, reconstituer des décisions, ou relancer pour savoir qui prend la suite, une partie du travail n'a pas disparu : elle a juste changé de main. À l'échelle d'une équipe, ce déplacement peut annuler le gain annoncé par l'expéditeur - et créer des frictions, des retards, voire des erreurs de coordination.

Les chercheurs de BetterUp Labs et du Social Media Lab de Stanford ont proposé le terme workslop pour décrire des contenus produits avec l'IA qui semblent aboutis, mais ne contiennent pas la "matière" nécessaire pour faire avancer une tâche. Dans leur enquête de 2025 auprès de 1 150 employés de bureau américains, 40 % des répondants disaient en avoir reçu au cours du mois précédent. Les destinataires estimaient que chaque incident leur coûtait près de deux heures. La moitié associe ces contenus à une baisse de la perception des compétences de l'expéditeur, et 32 % disent être moins enclins à retravailler avec lui.

À noter : ce sont des estimations déclarées, pas une mesure universelle du temps perdu. Mais le mécanisme, lui, est facile à retrouver dans la pratique : la qualité apparente du texte ne dit pas si le travail est réellement exploitable.

L'erreur factuelle n'est qu'un cas parmi d'autres

Un texte peut être grammaticalement propre, sans invention manifeste, et pourtant obliger le destinataire à reprendre le travail. Par exemple :

• une synthèse restitue des faits, mais oublie une contrainte qui change la décision ;
• un courriel donne du contexte, sans formuler clairement la demande ;
• un compte rendu liste des sujets, sans préciser les prochaines actions ;
• une mise à jour annonce un résultat, sans indiquer d'où vient le chiffre ;
• une réponse client est bien rédigée, mais ne traite pas l'engagement pris auparavant.

Le problème n'est donc pas seulement de savoir si l'IA a "raison". La vraie question est : est-ce que le livrable permet à la personne suivante d'agir, sans réparation disproportionnée ? Cette distinction aide autant les équipes produit, commerciales ou administratives que les contextes où la vérifiabilité est cruciale - par exemple pour des documents liés à la conformité ou aux obligations du RGPD.

L'IA reste un outil de production. La responsabilité du transfert, elle, reste humaine : l'expéditeur choisit ce qu'il envoie, à qui, et avec quel niveau de vérification attendu.

Demander ce qui a été refait, pas si le texte était "utile"

Pour tester un transfert, partez d'un livrable récurrent : une synthèse de recherche, un compte rendu de réunion, une mise à jour hebdomadaire, ou un courriel client préparé avec l'aide de l'IA. Envoyez-le comme d'habitude, puis, une fois que le destinataire s'en est servi, posez-lui :

Qu'avez-vous dû vérifier ou refaire ?

La formulation change beaucoup. « Est-ce que c'était utile ? » amène souvent une réponse polie et vague. « Est-ce que cela vous a fait gagner du temps ? » ramène le débat à l'impression de l'expéditeur, qui ne voit pas toujours ce qui a été repris après coup. « Qu'avez-vous dû vérifier ou refaire ? » pousse plutôt à décrire une action concrète.

La réponse peut prendre la forme d'une liste : « J'ai vérifié le chiffre de conversion et recherché le lien vers l'étude. » Elle peut aussi être « rien ». Les deux cas sont utiles : dans le premier, vous tenez une piste de correction ; dans le second, vous obtenez un premier signal que, dans ce contexte-là, le livrable est exploitable.

Choisir un test simple et représentatif

Commencez par un seul type de transfert. Assez fréquent pour être observé à nouveau, et assez limité pour que la correction reste faisable. Par exemple : une mise à jour adressée chaque semaine à la même équipe. À l'inverse, mixer dans une même enquête un message interne, une note juridique et une réponse au service client donne rarement quelque chose de comparable : les critères de qualité ne sont pas les mêmes.

Pour chaque essai, notez seulement quatre éléments :

1. Le type de livrable : compte rendu, synthèse, courriel ou autre.
2. Le destinataire et son usage : informer, décider, valider, exécuter.
3. La première vérification ou reprise mentionnée.
4. La correction apportée avant l'envoi suivant.

Présentez la démarche comme un ajustement du processus, pas comme une évaluation de la personne. Si le destinataire pense que son retour servira à juger un collègue, il risque de minimiser le problème. L'objectif est de repérer une friction qui revient et de la réduire, pas de chercher un coupable.

Écouter la première friction, sans tout vouloir corriger d'un coup

La première chose citée est souvent le meilleur point de départ, parce qu'elle reflète ce qui a vraiment gêné le destinataire dans son usage. Ce n'est pas toujours, "en théorie", le défaut le plus grave. Mais c'est un signal concret à traiter. Si plusieurs personnes pointent la même difficulté, vous avez un indice plus solide qu'une simple question de style.

Et gardez-vous d'ériger une réponse isolée en règle. Un destinataire a peut-être eu un besoin inhabituel, ou manquait d'un contexte que les autres ont. Vérifiez si la friction revient sur le transfert suivant avant d'imposer un nouveau format à toute l'équipe.

Corriger la cause, pas seulement le document reçu

Un retour ne sert que s'il mène à un changement visible. Si le destinataire a dû rouvrir les sources, ajoutez les références à côté des affirmations importantes. S'il a cherché l'action attendue dans un long courriel, mettez-la dès la première ligne. S'il ne savait pas qui devait agir après une réunion, ajoutez un responsable et une échéance aux décisions.

Le niveau de correction doit rester proportionné. Une vérification manuelle de chaque phrase peut être justifiée pour une information à fort enjeu, mais elle sera trop lourde pour une note interne à faible risque. Et se contenter d'écrire « généré par IA » ne rend pas un chiffre vérifiable ni ne clarifie qui porte la responsabilité. Ajustez le contrôle et la mise en forme selon l'usage du livrable.

Une règle simple : transformez chaque retour en changement à l'endroit où le défaut naît :

• Problème de demande : préciser l'objectif, le public et l'action attendue dans la consigne donnée à l'IA.
• Problème de source : exiger les références, puis vérifier que les liens ou documents soutiennent bien les affirmations.
• Problème de contexte : inclure les contraintes de décision plutôt que demander une synthèse "générique".
• Problème de responsabilité : ajouter le responsable, la prochaine étape, et si nécessaire l'échéance.
• Problème de ton ou de longueur : fournir un exemple adapté au destinataire et fixer des limites utiles.

Garder une boucle courte

Une fois le processus modifié, envoyez le livrable suivant comme d'habitude. Reréinterrogez ensuite : « Qu'avez-vous dû vérifier ou refaire ? » L'idée est de voir si la friction ciblée disparaît, et si une autre difficulté apparaît.

Cette boucle est souvent plus efficace qu'une réécriture générale des consignes après chaque incident. Elle aide à distinguer un défaut ponctuel d'un problème de structure, et évite les changements inutiles. Si la même reprise revient après plusieurs essais, la cause est probablement dans le processus : informations d'entrée incomplètes, format inadapté, ou tâche mal définie pour l'IA.

Exemple : une mise à jour de projet

Une équipe envoie chaque vendredi un résumé à partir de notes de suivi. Une responsable répond qu'elle a dû retrouver la source d'un chiffre avant de le présenter en comité. Dans ce cas, ce n'est pas forcément une question de changer de modèle ou d'ajouter un avertissement interminable. L'équipe peut plutôt associer la source à la donnée, distinguer les faits confirmés des estimations, et signaler les chiffres qui n'ont pas été vérifiés.

Au transfert suivant, la question reste la même. Si la responsable n'a plus besoin de rouvrir les sources pour comprendre d'où vient le chiffre, le changement a résolu une friction réelle. Si elle doit encore vérifier sa date ou son périmètre, le travail n'est pas fini : la prochaine correction doit viser cette information précise.

Mesurer le transfert dans son ensemble

Le temps de rédaction seul ne suffit pas. Pour évaluer un usage, regardez au minimum trois moments : le temps de préparation et de vérification côté expéditeur, le temps de reprise côté destinataire, et le délai avant que la tâche suivante puisse vraiment avancer.

Vous n'avez pas besoin de chronométrer chaque message au millimètre. Pour un test d'équipe, quelques observations suffisent : combien de fois le destinataire a-t-il dû revenir vers l'expéditeur ? A-t-il dû retrouver une source ? Le document a-t-il permis de décider, ou a-t-il surtout déplacé la discussion ? Les mêmes corrections reviennent-elles d'un envoi à l'autre ? Ces signaux donnent souvent une image plus utile que le nombre de mots générés ou la "vitesse" à l'écriture.

Un tableau simple peut aider à suivre la boucle :

Ce tableau ne prétend pas calculer à lui seul un retour sur investissement. Il sert surtout à voir si les reprises diminuent et si le résultat devient plus facile à utiliser.

Adapter le niveau de contrôle au risque

Tous les contenus ne demandent pas le même niveau de vérification. Une reformulation interne sans conséquence majeure n'a pas le même besoin de contrôle qu'un chiffre financier, une information RH, ou une communication client qui engage l'entreprise. Plus une erreur peut toucher une décision, une personne, ou une obligation réglementaire, plus la validation doit être explicite et attribuée.

En France et dans l'Union européenne, il faut aussi réfléchir à la nature des informations transmises aux outils : données personnelles, documents confidentiels, règles internes ne peuvent pas être traités comme de simples exemples de texte. Le respect du RGPD et des politiques de sécurité ne se limite pas à vérifier le résultat final : il concerne aussi les données envoyées au système et les personnes autorisées à les traiter.

Au fond, la bonne question n'est pas « faut-il tout vérifier tout le temps ? ». C'est : « quel niveau de contrôle correspond aux conséquences d'une erreur et à l'usage prévu ? » Cette approche évite autant la confiance aveugle que la revue exhaustive qui ferait s'évaporer le gain de temps.

Savoir quand arrêter... ou revoir l'approche

Si les retours deviennent plus rares, jusqu'à « rien », c'est plutôt bon signe pour ce transfert et ce destinataire. Ça ne prouve pas que "tout contenu IA" est fiable. Mais ça montre que, dans ce cas précis, le livrable ne déclenche pas de reprise évidente.

Si, au contraire, le destinataire doit réécrire le texte ou reconstruire des informations manquantes à chaque fois, il faut reconsidérer l'usage. L'IA n'est peut-être pas adaptée à cette étape, les données disponibles sont peut-être insuffisantes, ou le format de sortie ne colle pas au travail réel. Dans ce cas, mieux vaut réduire l'usage, changer le processus, ou confier à l'outil une partie plus limitée de la tâche plutôt que défendre un gain théorique.