Pourquoi la stratégie « IA d’abord » est une mauvaise approche – et ce qui fonctionne à la place

Les points clés en bref

Une grande partie de toutes les implémentations d’IA documentées dans les entreprises ne fournit pas les résultats promis. Le chiffre varie selon les sources, mais que l’on se réfère au MIT ou à des analystes du secteur : entre 80 et 95 pour cent des projets stagnent, sont discrètement abandonnés ou n’atteignent jamais la phase de production. Dans le même temps, la plupart des directions générales augmentent leurs budgets IA pour 2026. Ce n’est pas une contradiction – c’est un signal d’alarme. Car l’espoir n’est pas une stratégie.

L’industrie automobile fournit des exemples éloquents. La fillette de logiciels de Volkswagen, Cariad, a englouti des milliards avant que le groupe ne tire la sonnette d’alarme – non pas parce que la technologie n’existait pas, mais parce que l’organisation n’avait pas défini un problème clair et prioritaire. Au lieu de cela, tout devait être transformé en même temps. Le résultat : beaucoup d’infrastructure, peu de résultats. Cariad n’est pas un cas isolé. C’est le schéma qui se répète.

Pourquoi « AI-first » échoue systématiquement

L’erreur commence avec le cadrage. « AI-first » sonne comme de la détermination et une volonté d’innover. Dans la réalité opérationnelle, cela signifie généralement : une entreprise achète des outils d’IA et cherche ensuite des problèmes qui leur conviennent. C’est l’inversion de toute logique d’innovation qui fonctionne. La technologie ne résout pas des problèmes que personne n’a formulés.

Le premier symptôme est la solution sans problème. Les départements reçoivent des budgets pour « faire quelque chose avec l’IA ». Ils évaluent les outils, construisent des démos, présentent lors de journées d’innovation internes. Mais personne n’a demandé auparavant : quel processus concret voulons-nous améliorer ? De combien ? Et comment le mesurons-nous ? La conséquence : des projets pilotes qui fonctionnent techniquement, mais qui ne génèrent aucune valeur commerciale démontrable.

Le deuxième symptôme est la vague horizontale de PoC. De nombreuses entreprises lancent parallèlement dix, vingt ou plus de preuves de concept dans différents départements. Chaque équipe travaille avec des données différentes, des fournisseurs différents, des critères de réussite différents. Le résultat est un portefeuille d’expériences à moitié terminées, dont aucune ne franchit l’obstacle de la mise à l’échelle. Non pas parce que la technologie échoue, mais parce que personne n’a fait le travail préparatoire organisationnel – infrastructure de données, gouvernance, gestion du changement.

Le troisième symptôme est l’absence de véritables indicateurs de réussite. « Nous utilisons maintenant l’IA » est un communiqué de presse, pas un KPI. Tant que les entreprises mesurent le succès des projets d’IA au fait qu’ils existent ou non, au lieu de mesurer les améliorations en termes de délai de traitement, de taux d’erreur ou de réduction des coûts, les investissements restent un acte de foi. Et la foi ne se met pas à l’échelle.

Ce que les entreprises performantes font différemment

Les quelques entreprises dont les projets d’IA fonctionnent de manière prouvée partagent une caractéristique : elles ne traitent pas l’IA comme une stratégie, mais comme une discipline d’ingénierie. La différence peut sembler subtile, mais elle est fondamentale.

Priorisation verticale plutôt que dispersion horizontale. Au lieu d’introduire l’IA partout en même temps, ces entreprises identifient un processus concret présentant un fort potentiel de douleur et une grande disponibilité des données. Elles résolvent ce problème unique de manière exhaustive – de la nettoyage des données à la formation du modèle jusqu’à l’intégration dans le flux de travail opérationnel. Ce n’est qu’ensuite qu’intervient le prochain cas d’utilisation.

Des cas d’utilisation métier clairs avant le premier prompt. Avant même qu’une API ne soit connectée, un cas d’utilisation métier est présenté, qui quantifie les avantages attendus. Non pas dans des catégories vagues comme « l’amélioration de l’efficacité », mais en chiffres concrets : réduction du temps de traitement de 48 à 12 heures. Baisse du taux d’erreur de 8 à 2 %. Économie de 200 000 euros par trimestre. Celui qui ne peut pas citer ces chiffres n’a pas un projet d’IA – il a une hypothèse.

Augmentation plutôt que remplacement. Ici se ferme le cercle avec le débat Klarna, qui a de nouveau fait des vagues au milieu de 2025. Klarna avait choisi « AI-first » comme devise d’entreprise et avait systématiquement réduit les effectifs. Le résultat : une qualité de service en baisse, une frustration croissante des clients, un PDG qui a dû admettre publiquement que le calcul n’était pas rentable. Le contre-projet concerne les entreprises qui utilisent l’IA pour renforcer le travail humain. Un agent administratif qui traite deux fois plus de dossiers avec l’aide de l’IA crée plus de valeur qu’un robot qui répond faux une fois sur deux.

Le cadre Problem-first : trois questions avant chaque projet d’IA

Celui qui souhaite réduire le taux d’erreur de ses initiatives d’IA n’a besoin ni d’un nouvel outil ni d’un consultant supplémentaire. Il a besoin de discipline sur trois questions qui doivent être répondues avant le démarrage de chaque projet.

Première question : quel problème concret et mesurable ce projet résout-il ? Si la réponse est « Nous voulons utiliser l’IA », ce n’est pas un problème, mais un moyen. Retour au début.

Deuxième question : quelle est la valeur de référence actuelle, et quel est l’objectif ? Sans valeur de référence, il n’y a pas de progrès mesurable. Celui qui ne sait pas combien de temps un processus dure aujourd’hui ne peut pas juger si l’IA le rend plus rapide. Établir la référence est souvent plus fastidieux que de construire le modèle – et c’est précisément pourquoi elle est sautée. Erreur fatale.

Troisième question : que se passe-t-il si l’IA se trompe ? Chaque système d’IA a un taux d’erreur. La question n’est pas de savoir si des erreurs se produisent, mais s’il existe une position de repli. Dans le traitement des sinistres d’une compagnie d’assurance, un cas mal classé peut être un désagrément. Dans le diagnostic médical, c’est une catastrophe.

Ces trois questions ne constituent pas un cadre d’innovation pour les ateliers. Elles sont un filtre. Celui qui les répond honnêtement constatera que sur dix projets d’IA prévus, peut-être trois réussiront l’examen. C’est exactement le but. Trois projets bien réfléchis qui deviennent productifs valent mieux que trente pilotes qui se terminent par des présentations PowerPoint.

Check-list : prêt pour des projets d’IA ou juste pour des annonces d’IA ?

Cinq questions pour une détermination honnête de la position en deux minutes :

• Pouvez-vous citer une valeur cible concrète et mesurable pour chaque projet d’IA en cours ?
• Existe-t-il pour chaque projet un propriétaire de processus défini, responsable du succès – et pas seulement de la technique ?
• Avez-vous une base de données documentée pour les processus que l’IA est censée améliorer ?
• Existe-t-il une stratégie de repli en cas de défaillance du système d’IA ou de résultats erronés ?
• Le succès de vos initiatives d’IA est-il mesuré à l’aune de métriques métier – ou du nombre de projets lancés ?

Celui qui répond par oui à au moins quatre de ces questions travaille déjà selon l’approche problem-first. Tous les autres devraient affiner leur feuille de route pour l’IA au lieu de l’étendre. Moins de projets, plus d’impact. Moins de vision, plus d’ingénierie. Moins d’« AI-first », plus de « Problem-first, AI-enabled ». Ce n’est pas un frein à l’innovation. C’est la condition préalable pour que l’innovation aboutisse.

Foire aux questions

Source de l’image de titre : Unsplash / Scott Graham

À lire aussi

• Le pilote d’IA fonctionne, pas l’exploitation régulière
• Dette technique : Pourquoi le conseil d’administration doit agir maintenant
• Digitalisation sans Big-Bang : Transformation par étapes