Ce que coûte vraiment une adoption qui stagne à votre projet d'IA

Un chiffre échappe à presque tous les projets d'IA : le coût permanent de deux systèmes qui tournent en parallèle.

Le tableau de bord du projet affiche une adoption à 40 %. On y lit un problème d'achèvement, à régler avant la prochaine revue. En réalité, c'est un régime de croisière : deux façons de faire le même travail, indéfiniment, pour le double du coût de processus. Le nouveau système. Et les contournements.

Qu'est-ce que l'économie du contournement ?

Six mois après le lancement, le tableau ressemble généralement à ceci. Chacun saisit les données exigées dans le nouveau système : sur le papier, la conformité est respectée. Puis chacun ouvre son propre tableur, le dossier partagé de son équipe ou l'outil qu'il utilise depuis quatre ans, et fait le vrai travail là.

Ce n'est pas de la résistance. C'est un comportement rationnel. Le nouveau système ne gère pas l'exception qui se présente quarante fois par jour. Ou il produit des rapports dans un format que personne ne lit. Ou le circuit d'approbation demande trois clics de plus que l'ancien, et quand on le parcourt deux cents fois par semaine, cela compte.

Personne n'en a averti l'équipe de projet. L'équipe de projet n'observait pas le travail réel. Elle observait les indicateurs d'adoption.

Trois coûts absents de votre tableau de bord

1. Que devient la crédibilité de l'organisation ?

Les personnes qui travaillent par contournement ne se contentent pas de bouder votre système. Elles font un pronostic sur la prochaine initiative.

Quand une transformation d'envergure ne change pas la façon de travailler, elle laisse un dépôt. Le programme suivant, qu'il s'agisse de la couche d'IA posée sur un système resté inutilisé ou d'une tout autre initiative stratégique, démarre avec un déficit. Les équipes ont appris que l'écart entre « déployé » et « réellement utilisé » est grand, et elles dosent leur énergie de conformité en conséquence.

Ce déficit se voit mal sur un tableau de bord de programme. Il se voit dans la salle, quand vous annoncez la prochaine initiative et que vous observez les visages.

2. Le coût d'un double processus

Deux systèmes pour le même travail, ce n'est pas la moitié de l'efficacité d'un seul : c'est moins de la moitié, parce que chacun exige sa propre saisie, sa propre correction d'erreurs, sa propre charge de formation et son propre support. L'ancien système doit souvent rester en service à côté du nouveau, parce que le contournement en dépend.

Pour une équipe de cinquante personnes qui fait tourner des processus parallèles, ce surcoût n'est pas une erreur d'arrondi. C'est un coût structurel qui s'accumule chaque mois où l'adoption reste plate.

3. Quels cas d'usage ne pouvez-vous pas débloquer ?

La plupart des projets d'IA sont conçus par couches. La phase 1 fait entrer les données dans le système. Les phases 2 et 3 s'en servent pour produire quelque chose d'utile : prédiction, automatisation, meilleurs rapports. Les phases 2 et 3 supposent que les données de la phase 1 soient exactes, complètes et saisies par des personnes qui comprennent ce qu'elles saisissent.

À 40 % d'adoption, la qualité des données ne suffit pas pour la phase 2. La capacité sur laquelle vous aviez bâti l'argumentaire, celle qui a convaincu la direction de débloquer le budget, reste hors d'atteinte. Elle se trouve derrière un écart d'adoption que l'équipe de projet n'a plus les moyens de combler, puisque le projet est techniquement terminé.

Pourquoi une formation de plus n'y change-t-elle rien ?

Après une adoption ratée, le réflexe est d'organiser plus de formation. Plus de guides d'utilisation. Un deuxième événement de lancement. Une nouvelle série de communications sur le changement.

Ces mesures répondent à des lacunes de compétences. Or les problèmes d'adoption après mise en service ne sont presque jamais des lacunes de compétences. Les gens savent utiliser le système. Ils ont été formés. Ils choisissent de ne pas le faire, pour des raisons sans rapport avec leur capacité et tout à voir avec l'écart entre la conception du système et la réalité du travail.

On ne forme pas les gens à sortir d'un problème de conception de processus.

La cause structurelle

Les transformations calent pour une raison constante : les personnes qui doivent mettre le changement en œuvre n'ont pas participé à la décision sur son fonctionnement.

Le plan de mise en œuvre a été construit par celles et ceux qui ont conçu le système, validé avec les personnes concernées lors de revues formelles où personne ne soulève le problème des quarante exceptions par jour, puis lancé auprès de personnes qui avaient des objections fondées et jamais l'occasion de les exprimer.

Ces objections n'ont pas disparu. Elles sont devenues des contournements.

Communiquer davantage ne les fait pas émerger. Former davantage non plus. Ce qui les fait émerger, c'est un cadre structuré où les bonnes personnes, celles qui savent pourquoi cela ne marche pas et celles qui ont l'autorité pour le changer, réfléchissent ensemble au problème, d'une façon qui empêche les dynamiques habituelles d'étouffer ce qui doit être dit.

Par où avancer ?

Le premier pas est le diagnostic, pas l'intervention. Avant de concevoir un nouveau programme d'adoption, déterminez précisément où se situe la friction. Pas l'humeur générale : les moments concrets où les gens cessent d'utiliser le système, et pourquoi.

Le deuxième pas est de réunir les bonnes personnes autour de la table. Celles qui savent pourquoi cela ne marche pas. Celles qui ont l'autorité pour le changer. Une séance de travail structurée où les deux groupes réfléchissent ensemble au problème, avec des méthodes qui font contribuer chaque voix, y compris celles qui se taisent d'habitude.

Le troisième pas est l'engagement, pas la conformité. Le résultat de cette séance n'est pas un nouveau plan de communication. C'est un ensemble de décisions prises par celles et ceux qui devront les mettre en œuvre, consignées avant que quiconque quitte la salle.

C'est ce qui fait passer l'adoption de 40 % à un fonctionnement réel.