L'IA ne sauvera pas un mauvais processus. Elle fera juste la mauvaise chose plus vite et moins cher.

Dans les comités de direction revient une phrase qui ressemble à une stratégie sans en être une : il nous faut déployer de l'IA. On cherche un processus auquel brancher un modèle, on choisit un prestataire, on lance un pilote. Six mois plus tard, l'entreprise possède une licence et les mêmes chiffres qu'avant.

La cause ne tient pas à la faiblesse des modèles, mais à l'ordre des opérations. La technologie est une réponse, pas une question. La question est de savoir ce qui, dans le processus, empêche le travail de traverser l'entreprise sans s'arrêter. Si personne ne la pose, l'IA se contente d'accélérer la forme actuelle du travail, déformations comprises.

Automatiser un processus inefficace sans le repenser ne produit pas une amélioration, mais la mise sous cloche d'une mauvaise architecture de travail. La mauvaise chose se met à se produire plus vite et pour moins cher, ce qui est pire que lorsqu'elle se produisait lentement et à prix fort. Au moins, elle faisait alors assez mal pour que quelqu'un la voie.

La technologie n'est pas une stratégie

Michael Hammer a écrit dans la Harvard Business Review en 1990 une phrase qui n'a pas vieilli : les investissements massifs en technologies de l'information ont déçu principalement parce que les entreprises se servent de la technologie pour mécaniser d'anciennes façons de travailler. Elles laissent les processus existants intacts et se contentent de les accélérer avec des ordinateurs. Sa conclusion : arrêtez de paver les sentiers de vaches.

Erik Brynjolfsson et Lorin Hitt, dans une étude de 2000, indiquent que les investissements informatiques sans changement organisationnel peuvent entraîner des pertes de productivité significatives, parce que les interactions négatives avec les pratiques existantes l'emportent sur les bénéfices. Non pas un effet nul, mais négatif. Selon eux, les investissements organisationnels complémentaires, c'est-à-dire les nouveaux processus et les nouvelles compétences, peuvent représenter un ordre de grandeur d'environ dix fois l'investissement technologique lui-même.

Les chiffres plus récents vont dans le même sens, mais ne se lisent qu'avec des réserves. Le rapport The GenAI Divide, publié en juillet 2025 par le projet MIT NANDA, indique que malgré 30 à 40 milliards de dollars investis dans l'IA générative, 95 pour cent des organisations ne constatent aucun retour et que seuls 5 pour cent des pilotes dégagent une valeur qui se chiffre en millions de dollars. Le rapport repose sur 52 entretiens et 153 questionnaires du premier semestre 2025, ses auteurs qualifient leurs conclusions de préliminaires, reconnaissent un biais de sélection et n'ont pas publié les données sous-jacentes. C'est donc un indice, pas une mesure du marché. Leur explication compte davantage : les projets n'échouent ni sur la qualité des modèles ni sur la réglementation, mais sur la fragilité des workflows et sur l'inadéquation avec le quotidien opérationnel.

Dessinez d'abord le flux, l'architecture ensuite

Le process redesign, autrement dit la refonte du déroulement du travail avant tout choix d'outil, commence de façon ennuyeuse : vous décomposez un processus en quatre types d'étapes. L'entrée est le signal ou la donnée qui pénètre dans le processus. La décision est l'endroit où l'on choisit entre plusieurs options. L'action modifie un état. La sortie est ce qui ressort du processus et dont quelqu'un d'autre se sert. L'objectif est de séparer les étapes qui créent de la valeur de celles qui ne font que déplacer de l'information.

On cartographie la réalité, pas la procédure officielle. Le manager décrit le circuit validé. La personne qui fait le travail vous montrera aussi le tableur que l'équipe s'est créé parce que le système officiel ne suffit pas. Ces contournements sont la meilleure carte des défauts de conception.

Ce qu'il faut chercher dans le flux

• La duplication. La même information est saisie à plusieurs endroits, et chaque saisie est une nouvelle occasion de divergence.
• L'attente. Le dossier stagne et personne ne s'en occupe. C'est souvent le premier poste du temps total.
• La validation sans risque. Une signature qui n'a jamais rien refusé n'est pas un contrôle, c'est un rituel qui a un coût.
• Le transfert manuel. Recopier un mail dans un tableur, exporter et importer, copier d'un système à l'autre.
• Les étapes sans raison d'être. Un rapport que personne ne lit. Une copie pour un auditeur qui n'en veut plus.

Nous classons les constats avec la formule du Cost of Friction : durée d'une occurrence multipliée par la fréquence, par le nombre de personnes impliquées et par le coût horaire. Une étape qui ne dure qu'un instant, mais que toute une équipe répète chaque jour, revient souvent plus cher qu'un gros projet traité une fois par an. Pourquoi la plupart des entreprises n'ont pas besoin d'un outil de plus, mais de moins de chaos, nous l'avons développé dans l'article Votre entreprise n'a pas besoin de plus de logiciels. Elle a besoin de moins de chaos.

La méthode : supprimer, simplifier, automatiser, augmenter

L'ordre est volontairement impitoyable. On ne passe à l'étape suivante qu'une fois la précédente terminée, car chacune est plus coûteuse et moins réversible que celle qui la précède.

Supprimer

La première question n'est pas comment aller plus vite, mais s'il faut vraiment le faire. Une étape supprimée a un coût d'exploitation nul, un taux d'erreur nul et une maintenance nulle. Qui la saute automatise du travail qui n'aurait jamais dû exister.

Simplifier

Ce qui reste doit être raccourci. Moins de champs, moins de statuts, moins d'exceptions, moins de niveaux de validation. La simplification réduit d'un coup les coûts, le taux d'erreur et le temps de formation, sans une seule ligne de code. Qui la saute automatise des exceptions. Or chaque exception réclame sa propre règle, son test et sa maintenance.

Automatiser

C'est seulement ici qu'arrive l'outil. On automatise ce qui est répétable, univoque et fréquent, et l'essentiel de cette couche n'a pas besoin d'IA. Sauter directement au modèle est une erreur que nous voyons revenir dans les cahiers des charges. L'entreprise déploie un modèle sur une tâche qu'une règle aurait réglée, et paie pour une incertitude dont elle n'avait pas besoin.

Augmenter

La dernière couche ne remplace pas la personne, elle étend sa portée. On y trouve la synthèse de documents, le premier jet d'un texte ou le tri de données non structurées, autrement dit des tâches sans réponse unique. Qui commence directement ici obtient une démo impressionnante et aucun changement dans les chiffres, c'est-à-dire exactement l'inadéquation opérationnelle décrite par le rapport du MIT.

La différence entre automatisation et refonte apparaît dans l'exemple Ford cité par Hammer. Au début des années quatre-vingt, le service comptabilité fournisseurs pour l'Amérique du Nord employait plus de 500 personnes et la direction attendait des nouveaux systèmes informatiques une réduction des effectifs d'environ 20 pour cent. Après la refonte, lorsque le rapprochement a porté sur trois données au lieu de quatorze et que la facture du fournisseur a été supprimée purement et simplement, Ford a obtenu, là où le nouveau processus a été mis en place, une réduction des effectifs de 75 pour cent. Ces pourcentages séparent l'accélération d'un ancien mode de fonctionnement de la conception d'un nouveau.

Quand une règle suffit et quand il faut un modèle

L'automatisation déterministe rend toujours la même sortie pour la même entrée. Elle couvre la workflow automation : connexion des systèmes, conditions, validations, génération de documents, notifications. Elle est peu coûteuse, testable, et lorsqu'elle échoue, elle échoue bruyamment et à un endroit connu. Un large language model, autrement dit un grand modèle de langage, est probabiliste. La même entrée peut produire une sortie différente et le modèle n'a aucun moyen fiable d'admettre qu'il ne sait pas. En revanche, il traite le langage et l'entrée non structurée, ce dont une règle est incapable.

Si la marche à suivre tient dans une phrase du type quand A se produit, faire B, utilisez une règle. Si la tâche ne peut s'exprimer que par des exemples, le modèle est justifié. Et si la règle peut s'écrire mais que personne n'a envie de s'y mettre, ce n'est pas un argument en faveur de l'IA, c'est une décision repoussée.

Selon le benchmark TheAgentCompany, conçu par des chercheurs de Carnegie Mellon University pour simuler l'environnement d'une petite entreprise logicielle, le meilleur agent testé a mené à bien 30 pour cent des tâches en toute autonomie. Il s'agit d'une simulation et d'une réalisation entièrement autonome, le chiffre ne dit donc rien de ce qu'un agent accomplit avec une personne à ses côtés. Il en ressort tout de même ceci : un agent lancé sur un processus mal rangé n'ira pas au bout de la majorité du travail.

Où l'humain doit rester

Le human in the loop, autrement dit l'intégration d'une personne dans la boucle de décision, est une bonne idée souvent détournée en alibi. Ben Green, dans une étude évaluée par les pairs, a examiné 41 politiques imposant une supervision humaine des algorithmes publics. Selon ses conclusions, les personnes ne parviennent pas à exercer les fonctions de supervision que l'on attend d'elles, et ces politiques de supervision légitiment donc le déploiement d'outils défaillants.

La réglementation européenne le reconnaît. L'article 14 du règlement sur l'intelligence artificielle exige que les systèmes à haut risque soient conçus de façon à pouvoir être effectivement contrôlés par des personnes, et nomme explicitement l'automation bias, c'est-à-dire la tendance à se fier automatiquement à la sortie du système. Le mot clé est conçus. La supervision est une exigence de conception, pas un correctif collé après le déploiement.

L'humain doit donc rester là où la décision est irréversible, là où elle emporte des conséquences juridiques ou financières et là où il s'agit d'une exception qui sort des cas courants. Là où le contrôle ne serait que formel, mieux vaut ne pas automatiser l'étape du tout.

Les risques à traiter avant le lancement

Les hallucinations. Une mesure indépendante de l'équipe Stanford RegLab a montré que des outils juridiques spécialisés dotés d'une recherche documentaire hallucinaient dans 17 à 33 pour cent des cas, le meilleur des outils testés répondant correctement à 65 pour cent des questions. Son fournisseur promettait pourtant zéro hallucination. Le domaine est la recherche juridique aux États-Unis, ne transposez donc pas les chiffres mécaniquement. Ce qui se transpose, c'est la conclusion : même un outil adossé à une base vérifiée se trompe assez souvent pour que sa sortie exige un contrôle. Selon le travail Why Language Models Hallucinate, dont la majorité des auteurs travaillent chez OpenAI, il ne s'agit pas d'un défaut que la version suivante corrigera. Les modèles devinent parce que le mode d'évaluation récompense la devinette et sanctionne l'aveu d'incertitude.

La confidentialité et les données. La data governance, autrement dit les règles définissant quelles données entrent dans le système et qui en répond, n'est pas une surcouche administrative. L'article 10 du règlement sur l'intelligence artificielle exige que les jeux de données d'entraînement, de validation et de test soient pertinents, suffisamment représentatifs et, dans toute la mesure du possible, exempts d'erreurs. Un modèle branché sur des données mal tenues fige le désordre et lui confère l'autorité d'une sortie machine.

Les droits d'accès. Un assistant qui voit tout ce que voit le disque partagé de l'entreprise est une nouvelle surface de fuite. Des droits trop larges sont hérités par le modèle, qui facilite la recherche dans ce qui devait rester cloisonné.

L'auditabilité. L'article 12 exige que les systèmes à haut risque permettent techniquement l'enregistrement automatique des événements tout au long de leur cycle de vie. La capacité de reconstituer après coup ce que le système a fait et sur quelle base se conçoit en amont. Elle ne se recolle pas sur un processus déjà en production.

Le cadre américain NIST AI RMF y ajoute une étape facile à omettre : la cartographie des risques doit déboucher sur une décision initiale, celle de savoir si une solution fondée sur l'IA doit seulement être construite.

Exemple type : de la demande à l'offre

Une entreprise fictive vend des composants sur mesure. Situation actuelle :

1. La demande arrive dans une boîte mail partagée.
2. L'assistante la recopie dans un tableur et crée un dossier sur le disque partagé.
3. Le commercial vérifie par mail auprès d'un technicien si la demande est réalisable.
4. Le technicien répond quand il en a le temps.
5. Le commercial assemble l'offre à la main et recopie les prix depuis le catalogue tarifaire.
6. Le responsable valide l'offre, dans les faits toujours.
7. L'offre arrive dans le CRM quand quelqu'un y pense.

La solution naïve consiste à déployer un modèle de langage qui rédigera les offres à partir des mails. L'entreprise obtient une production de documents plus rapide, mais l'attente du technicien, la double saisie et la validation vide subsistent. Naît alors une version plus rapide du même désordre, et une nouvelle catégorie d'erreurs que personne ne contrôle.

La refonte selon la méthode donne autre chose. Supprimer : on élimine la recopie dans le tableur ainsi que la validation qui n'a jamais rien refusé, remplacée par un plafond. Simplifier : la demande arrive via un formulaire qui réclame les paramètres nécessaires à l'évaluation, si bien que la question au technicien disparaît la plupart du temps. Automatiser : le formulaire crée de façon déterministe l'opportunité dans le CRM, affecte un commercial, assemble l'offre à partir du catalogue tarifaire et surveille les échéances. Aucun modèle n'est nécessaire ici. Augmenter : c'est seulement pour les demandes atypiques que le modèle prépare une synthèse et une proposition de solution, que le technicien confirme ou réécrit.

Notez l'ordre. L'effet le plus important est venu des deux premières étapes, qui n'ont presque rien coûté et n'ont pas eu besoin d'IA. Une remarque que notre métier formule rarement : une part non négligeable de ces missions se règle sans développement spécifique, c'est-à-dire en supprimant des étapes, avec un formulaire et un outil du commerce dont l'abonnement coûte un ordre de grandeur de moins que le développement et sa maintenance. Une solution sur mesure a du sens là où le processus est réellement spécifique et où la friction dépasse le prix du développement et de la maintenance. Le moment où un tel investissement devient rentable, nous l'analysons dans le texte Un bon système interne peut s'amortir plus vite qu'un nouveau salarié, et à quoi ressemblerait une entreprise construite à partir de zéro, dans l'article Comment je construirais aujourd'hui une entreprise qui n'a pas besoin d'une armée d'administratifs.

Ce qu'il faut retenir

• Décomposez un processus en entrée, décision, action et sortie. Cartographiez la réalité, pas la procédure officielle.
• Repérez la duplication, l'attente, les validations sans risque, les transferts manuels et les étapes sans raison d'être. Classez-les selon le Cost of Friction : durée multipliée par la fréquence, par le nombre de personnes et par le coût horaire.
• Tenez l'ordre supprimer, simplifier, automatiser, augmenter. Une étape ne commence qu'une fois la précédente terminée.
• Là où l'automatisation déterministe suffit, un modèle de langage n'ajoute que de l'incertitude et du coût.
• Avant le lancement, répondez à ces questions : qui contrôle la sortie, quelles données entrent, qui a accès à quoi et comment prouverez-vous après coup ce que le système a fait.