Vous avez acheté les licences du copilote. Il y a eu un courriel de lancement, peut-être une formation. Et trois mois plus tard, quand vous regardez l'usage réel, la plupart des gens ne l'ont pas ouvert cette semaine. Ce n'est pas que vous : Microsoft a rapporté environ 15 millions d'utilisateurs payants de Copilot pour quelque 450 millions de licences Office commerciales —environ 3% d'adoption réelle— et en 2026 l'usage hebdomadaire actif typique se situe entre 20 et 30% des postes sous licence. La conclusion gênante est là : le copilote IA interne n'échoue pas sur le modèle. Il échoue parce que personne ne l'utilise.
La thèse en une phrase : un copilote interne meurt sur l'adoption, pas sur la capacité. Le modèle est presque toujours assez bon ; ce qui échoue, c'est l'insertion dans le flux de travail réel et l'accès aux données qui rendent la réponse utile. Sans ces deux choses, la licence chère reste fermée —et le problème ne se règle pas en achetant un meilleur modèle.
Pourquoi le copilote IA interne reste fermé
Le schéma d'abandon est si constant qu'il est désormais documenté : les gens essaient le copilote une ou deux fois, se rendent compte que relire et corriger le brouillon qu'il génère prend plus de temps que de l'écrire eux-mêmes, et cessent de l'utiliser. La chute d'usage arrive la première semaine, pas la première année. Ce n'est pas de la paresse ni une résistance au changement : c'est une décision rationnelle. Si l'outil vous coûte plus qu'il ne vous fait gagner sur votre tâche précise, l'abandonner est le bon choix.
Et voici l'erreur de diagnostic qui se paie cher : quand l'adoption stagne, la réaction typique est de penser que le modèle est insuffisant et d'en chercher un meilleur. Mais les données pointent l'inverse —la perception de l'utilisateur diverge de la qualité du modèle— ce qui désigne l'expérience produit et l'exécution de l'intégration, pas la capacité. Changer de modèle quand le problème est l'insertion, c'est dépenser sur le mauvais levier.
Les trois vraies raisons pour lesquelles l'adoption s'effondre
Sous le « ils ne l'utilisent pas » il y a des causes concrètes, et aucune ne se règle avec un modèle plus puissant.
- Il ne s'insère pas dans le flux de travail. Le copilote vit dans un onglet à part et le travail vit ailleurs. Si l'utiliser oblige à sortir du flux, copier le contexte et revenir, la friction mange le gain. L'outil doit être là où l'on travaille déjà, pas dans une fenêtre à aller chercher.
- Il n'a pas les données à portée. Un copilote qui ne connaît pas vos politiques, votre historique ni vos systèmes répond générique —et le générique, il faut le réécrire en entier. Le saut d'« assistant qui rédige des choses plausibles » à « assistant qui répond avec vos données » est ce qui sépare un jouet d'un outil.
- Personne n'a montré qu'il marche sur une tâche réelle. Sans un cas visible dans l'équipe —quelqu'un qui l'utilise pour quelque chose de concret et gagne vraiment du temps— il n'y a pas de preuve sociale pour entraîner le reste. Les gens n'adoptent pas sur un courriel ; ils adoptent quand ils voient un collègue résoudre en deux minutes ce qui leur prend vingt.
Il y en a une quatrième, silencieuse : les doutes sur la sécurité et les données que personne n'a levés. Si l'équipe ne sait pas si ses prompts entraînent le modèle ou si elle peut y mettre des données client, beaucoup ne l'utilisent simplement pas —et ne le disent pas. Cette incertitude tue l'adoption sans laisser de trace dans aucun sondage.
Un copilote n'est pas un agent : la nuance qui change le projet
Une partie du problème est d'attendre du copilote une chose qu'il ne fait pas, par conception. Un copilote assiste une personne : il attend votre instruction, rédige, résume, cherche. Il brille dans le ponctuel et meurt dans le répétitif qui traverse plusieurs apps —recueillir ce qui arrive par courriel et le laisser structuré, tenir une fiche cohérente dans trois endroits, monter un dossier à partir de l'épars. Ça, ce n'est pas un copilote qui attend des ordres qui le fait ; c'est un agent administratif qui travaille seul. Décider laquelle il vous faut est la première question de quels processus automatiser avec l'IA : si le travail est d'assister des personnes, copilote ; si c'est de retirer du travail de clavier répétitif, agent. Vendre un copilote là où il fallait un agent est une garantie de déception, et inversement.
Comment on règle l'adoption (et ce n'est pas avec un autre modèle)
Si l'adoption est le problème, l'adoption est là où l'on investit. En pratique, ce sont quatre mouvements, aucun sur le modèle :
- Mettre le copilote dans le flux réel. Là où l'on travaille déjà —le CRM, le helpdesk, le document— pas dans un onglet à part. S'il faut aller le chercher, il n'est pas utilisé.
- Lui donner les données à portée. Le connecter à vos politiques, votre historique et vos systèmes pour qu'il réponde avec vos données et non le générique. C'est là qu'un copilote passe de plausible à utile.
- Choisir 2-3 tâches concrètes et les démontrer. Pas « utilisez l'IA » : « pour ce type de courriel, ce prompt vous fait gagner quinze minutes ». Un cas visible qui marche entraîne plus que dix formations.
- Répondre à la question de sécurité avant qu'ils la posent. Ce qu'il advient des données, ce qu'on peut y mettre et ce qu'on ne peut pas. La confiance est un prérequis d'usage, pas un extra.
C'est, au fond, la même raison pour laquelle les projets d'automatisation avec l'IA échouent : on achète de la techno et on saute l'insertion dans le travail réel et les personnes qui le font. La technologie est la partie facile ; qu'elle soit utilisée est la difficile, et c'est elle qui décide du retour. C'est pourquoi le travail qui fait vraiment bouger l'aiguille n'est pas de choisir un modèle, c'est l'adoption de l'IA dans les équipes : insertion dans le flux, données connectées, cas démontrés et doutes levés.
La question à se poser avant de renouveler les licences
Quand le renouvellement arrivera et que vous verrez l'usage plat, la tentation sera de changer de fournisseur ou de modèle. Avant, posez la question qui ordonne le problème : les gens ne l'utilisent-ils pas parce que le modèle est mauvais, ou parce qu'il ne s'insère pas dans leur travail et n'a pas les données à portée ? C'est presque toujours la seconde. Et ça ne se règle pas en achetant —ça se règle en montant l'adoption comme un projet avec un propriétaire, pas comme un courriel de lancement. Un copilote que personne n'utilise n'est pas un problème d'IA : c'est une licence chère qui attend que quelqu'un fasse le travail de la faire utiliser.