Piloter la transition IA : pourquoi tant de projets échouent, et comment l’éviter
Un projet IA échoue rarement de façon spectaculaire. Les licences restent payées, l’outil reste disponible, l’usage se tasse, et personne ne prend la décision de l’arrêter. Six mois plus tard, la direction financière pose la question et personne n’a de réponse à lui donner.
La technologie n’est presque jamais en cause dans ces situations : elle fonctionne. Les cinq causes qui reviennent relèvent toutes de l’organisation, et quatre d’entre elles se traitent avant le déploiement.
Les cinq causes qui reviennent
1. On a distribué au lieu de cibler. Des licences réparties uniformément « pour faire de l’IA », sans que personne ait dit à qui elles servaient et pour quelle tâche. Chacun essaie deux semaines, ne trouve pas sa place, et arrête. C’est la cause la plus fréquente et la plus coûteuse.
2. Les données n’étaient pas prêtes. L’assistant restitue à chacun tout ce qu’il a le droit de voir. Dans un environnement dont les permissions se sont élargies au fil des années, les premières réponses gênantes arrivent vite, la confiance tombe, et le projet est suspendu pour de mauvaises raisons — le problème n’était pas l’outil.
3. Personne n’était responsable de l’adoption. L’informatique a livré, les métiers ont reçu, et le milieu est vide. Microsoft place explicitement la formation et l’éducation des utilisateurs, la configuration des politiques d’usage et le contrôle des résultats du côté du client, y compris pour une solution entièrement gérée. Ce n’est pas une charge que l’éditeur prend.
4. On a promis un résultat qu’on ne pouvait pas mesurer. Un gain de productivité annoncé en comité, aucun point de départ relevé, aucune métrique existante. Douze mois plus tard, la conversation devient impossible : ni preuve, ni réfutation, et la confiance s’use.
5. Le pilote n’avait pas de lieu d’échange. Des utilisateurs isolés qui essaient chacun dans leur coin, sans que ce qui fonctionne chez l’un se propage aux autres. Une heure de point hebdomadaire aurait suffi à corriger cela.
Le moment où un déploiement décroche
Le risque ne se situe pas au lancement mais quelques semaines plus tard, une fois l’enthousiasme initial retombé. Les usages faciles sont acquis, les usages plus profonds demandent un effort que personne n’accompagne, et les premières questions de gouvernance remontent au même moment. C’est la période où un projet a besoin d’un relais, et c’est aussi celle où l’équipe qui a mené le lancement est déjà passée à autre chose.
Microsoft structure son propre guide de déploiement en trois temps qui tiennent compte de ce risque : un pilote sur un petit groupe pour tester et recueillir des retours, un déploiement élargi, puis une phase d’exploitation consacrée à la surveillance de l’usage et de l’adoption. Cette troisième phase est celle que la plupart des organisations laissent de côté, et c’est pourtant elle qui décide du résultat.
Ce qu’une direction peut décider avant de commencer
Quatre décisions, aucune n’est technique.
- Nommer la fonction responsable de l’adoption, avec du temps dégagé, pas en plus du reste. Sans cela, la troisième phase n’aura pas lieu.
- Choisir le périmètre par le volume d’usage, pas par la hiérarchie. Le centre d’administration expose d’ailleurs un rapport de préparation qui signale les utilisateurs les plus susceptibles de tirer parti de l’outil, sur la base de leur activité.
- Fixer ce qui sera mesuré, et relever le point de départ avant la première licence.
- Traiter les droits d’accès avant d’ouvrir la recherche dans le patrimoine documentaire.
Remarque : ce rapport de préparation porte un avertissement explicite de Microsoft — ces données ne sont pas destinées à évaluer la performance des collaborateurs. C’est un point à tenir fermement. Un rapport d’usage utilisé, même une seule fois, comme instrument d’évaluation individuelle détruit l’adhésion pour de bon, et aucune communication ne la rattrape ensuite.
Notre lecture
La cause d’échec dont on parle le moins est aussi la plus banale : le projet n’appartenait réellement à personne. Un sponsor de direction qui ouvre la réunion de lancement n’en est pas le propriétaire. Le propriétaire est celui dont l’agenda contient, chaque semaine pendant six mois, une heure consacrée à ce sujet.
Notre recommandation est directe : si vous ne pouvez pas nommer cette personne et dégager ce temps, ne lancez pas. Achetez cinq licences, laissez les curieux explorer et revenez au sujet lorsque la ressource existera. Un déploiement large sans propriétaire ne produit pas un demi-résultat mais un échec visible, qui rendra le prochain essai nettement plus difficile à financer.
Une idée reçue mérite d’être corrigée au passage. Beaucoup de directions traitent la résistance des équipes comme le risque principal et bâtissent un plan de communication en conséquence, alors que l’opposition frontale est rare. Ce qui est fréquent, c’est l’indifférence polie : les gens ne s’opposent pas, ils n’essaient simplement pas, parce que personne ne leur a montré ce que l’outil change dans leur propre journée. Une campagne de communication n’y peut rien, là où une démonstration de quinze minutes sur leur travail réel change souvent la donne.
Pour ceux qui ont déjà échoué une fois, la situation est récupérable, mais pas en relançant la même chose. Il faut changer explicitement de cadrage — périmètre plus étroit, propriétaire nommé, mesure annoncée — et le dire aux équipes. Reprendre à l’identique après un premier échec conduit au même résultat, avec en prime une organisation qui ne croit plus au sujet.
Ce qu’il faut faire
- Nommez le propriétaire de l’adoption et inscrivez son temps à l’agenda. Si ce n’est pas possible, reportez le projet.
- Réduisez le périmètre initial jusqu’à ce qu’il tienne dans ce temps disponible.
- Relevez le point de départ de la métrique choisie avant la première licence.
- Traitez les droits d’accès avant d’ouvrir la recherche documentaire.
- Bloquez une heure hebdomadaire d’échange entre les utilisateurs du pilote, et tenez-la.
- Interdisez formellement l’usage des rapports d’activité à des fins d’évaluation individuelle, et faites-le savoir.
- Planifiez la phase d’exploitation dès le lancement. C’est celle qui décide du résultat, et c’est celle qu’on oublie.
Rien dans cette liste ne demande une compétence que vous n’avez pas en interne. Ce qui manque le plus souvent, c’est le temps et la position pour dire non à un périmètre trop large. Lambert Consulting peut tenir ce cadrage et l’assumer devant les métiers, ce qui est parfois plus facile de l’extérieur. La question de la mesure se traite au même moment, et la remise en ordre des droits d’accès reste le prérequis à ne pas contourner.
Les sources Microsoft
Ce qu'un article ne peut pas savoir
Un article décrit ce qui vaut pour tout le monde. Ce qui change d'une organisation à l'autre, c'est l'inventaire : quelles applications, quels comptes, quels équipements sont réellement concernés chez vous. C'est l'inventaire qui décide de l'effort, et il ne se répond pas sur une page.
Vous parlez aux ingénieurs qui feraient le travail, pas à un intermédiaire. Réponse sous 24 heures ouvrées.
Vérifier ce qui est encore vrai
Les dates annoncées sont parfois repoussées, les produits changent de nom, les conditions évoluent. Le blog suit ces sujets au fil du temps : quand une règle change, un nouvel article le dit.
Chercher un sujet dans le blogDans le même dossier
Trois articles du même sujet. Le blog en compte 149, tous en accès libre.