Pourquoi votre entreprise n’est pas prête pour l’IA
95 %. C’est la part des projets d’IA générative en entreprise qui n’arrivent jamais en production, selon le rapport NANDA publié par le MIT en 2025. Pas 95 % de pilotes bancals. 95 % de projets financés, suivis en comité, présentés en COMEX, qui meurent quelque part entre la démo qui marche et le déploiement qui ne marche pas.
La raison qu’on entend en réunion explique mal ce chiffre. La technologie bouge trop vite, on attend le bon outil, l’équipe n’est pas encore prête. Ce qu’on observe en mission est différent. Le bon outil ne manque pas, il y en a quinze. Ce qui manque, c’est un regard honnête sur le fonctionnement interne de l’entreprise. Et personne n’aime ce regard. Ni le directeur métier, ni la DSI, ni le COMEX, et souvent pas le DG non plus.
Ce papier décrit les trois problèmes qu’on rencontre régulièrement en mission et que les rapports stratégiques contournent. Il finit sur le chemin qui fonctionne, et sur cinq symptômes qui suffisent à reconnaître que votre organisation n’est pas prête pour l’IA.
Le faux problème : « on attend de choisir notre outil IA »
C’est la phrase qu’on entend dans huit entreprises sur dix au démarrage d’un projet. On attend la prochaine version de Claude, la prochaine release de Copilot, l’arbitrage entre Mistral et Gemini Enterprise. On se rassure en suivant l’actualité. On classe et reclasse les options dans un tableau Notion.
Le marché des outils est saturé. Les modèles convergent en performance, les agents existent, les intégrations Microsoft 365 et Google Workspace sont stables, le comparatif que nous tenons à jour sur les meilleurs LLM pour un usage professionnel recense cinq solutions sérieuses qui couvrent 90 % des besoins. Même la barrière du code est tombée, créer un agent en trente minutes sans écrire une ligne de code est aujourd’hui à portée d’un responsable métier curieux. Le retard ne vient pas de l’offre.
Il vient d’une confusion. Croire que choisir un outil suffira à transformer l’organisation. C’est précisément ce que nous décrivions quand nous expliquions qu’intégrer l’IA en entreprise est devenu un métier à part entière. Un bon outil branché sur un mauvais process produit un mauvais process plus rapide. Une réponse contractuelle automatisée par un grand modèle de langage sur un workflow où trois services négocient encore par mail en parallèle ne fait pas gagner du temps, elle ajoute une voix de plus à la cacophonie.
Le vrai démarrage n’est pas un appel d’offres pour un copilote. C’est un audit sans complaisance des process qu’on prétend automatiser. Et c’est là que ça coince.
Votre vrai SI vit ailleurs que dans votre ERP
Dans toutes les missions où on a commencé par cartographier les process, on retrouve le même type d’objet sous des formes différentes. Souvent un Excel maintenu seul depuis dix ans par Catherine, en comptabilité, avec une trentaine d’onglets, des formules imbriquées et des macros écrites un samedi matin en 2019. Personne d’autre dans la boîte ne sait dire ce que fait précisément l’onglet « recap-3 », et tout le monde s’en accommode tant que Catherine n’est pas en arrêt maladie. Mais l’Excel de Catherine n’est qu’un cas, et pas toujours le plus grave. C’est parfois un CRM dans lequel personne n’a structuré les opportunités ni discipliné les statuts, et qui sert plus de répertoire de contacts que de carte d’avancement commercial. C’est parfois une GED où les contrats s’appellent « v3-final-OK-bon », une base de tickets clients sans nomenclature de motifs, ou un dossier Drive ou SharePoint dont la version de référence n’est jamais celle qu’on croit. Sur le papier, ce sont des outils de gestion. Dans les faits, c’est là que vit le système d’information de fait de l’entreprise. L’ERP officiel sert à émettre les factures et stocker les contrats. La logique de décision, elle, est ailleurs.
Quand on entre dans ces espaces, on observe presque toujours la même répartition. Environ 30 % du contenu est inutile : vieux suivis, onglets archivés, fiches périmées, traces de chantiers abandonnés qu’on n’ose pas supprimer « au cas où ». Environ 30 % est faux ou incohérent : formules cassées, statuts non mis à jour, doublons, sources non synchronisées. Et environ 40 % est critique et n’existe nulle part ailleurs : règles métier non documentées, exceptions tarifaires, arbitrages internes négociés au fil des années, raisons d’avoir gagné ou perdu un contrat connues seulement par le commercial qui était dans la pièce.
Ce qu'on trouve dans les outils non documentés
Ce dernier tiers est le point dur. C’est lui qui fait que l’entreprise sait ce qu’elle fait. C’est aussi lui qui empêche tout projet IA de progresser. Tant qu’il vit dans la tête des opérationnels qui maintiennent l’outil au quotidien, aucun agent ne peut le reproduire, le contrôler, ni l’auditer. Quand nous expliquons comment alimenter une IA avec ses données, nous décrivons en détail le travail de préparation à effectuer. Ce travail vaut zéro tant que la donnée source n’a pas été extraite des Excels et des têtes.
L’IA n’efface pas votre SI fantôme. Elle l’expose. Et avant d’exposer, elle bute dessus. Tout le début d’un projet sérieux est de l’archéologie. Documenter ce qui se passe vraiment. Faire dire à voix haute ce que personne ne dit en réunion. Accepter que la moitié des process listés dans le manuel qualité ne décrit pas la réalité.
L’automatisation expose votre organigramme
Le deuxième problème est moins technique et plus politique. Modéliser un process pour l’automatiser, c’est en dessiner la mécanique. Et dessiner la mécanique d’une entreprise, c’est faire apparaître ce que personne n’a envie de voir. Les redondances. Les rôles flous. Les boucles de validation qui ne valident rien. Les chefs intermédiaires dont la fonction effective se résume à compiler ce que leurs équipes remontent et à le retransmettre vers le haut.
C’est une régularité de mission, pas un cas isolé. Sur les process qu’on redessine pour les automatiser, on rencontre fréquemment des chaînes de validation où la moitié des intervenants ne décide rien. Ils vérifient, paraphent, transmettent. Personne ne sait dire ce qu’il se passerait si on les retirait du circuit, parce que personne n’a jamais essayé. Un agent IA correctement câblé absorbe ces étapes en quelques secondes. Le bénéfice opérationnel est immédiat. Le bénéfice politique est nul. Quelqu’un vient de dire à plusieurs collaborateurs que leur tâche principale était assimilable par un script.
C’est cette mécanique politique, plus que la technique, qui explique le 95 % d’échec mesuré par le MIT. Les projets ne meurent pas parce que les modèles hallucinent. Ils meurent parce qu’au moment où l’automatisation commence à toucher un périmètre sensible, quelqu’un de bien placé dans l’organisation ralentit. Pas en plénière. Dans les arbitrages de calendrier, dans les rééquilibrages de scope, dans les « on va d’abord sécuriser cette autre brique avant d’aller plus loin ». L’autre brique n’arrive jamais.
Cette opposition silencieuse n’est presque jamais malveillante. Elle est légitime. Les gens défendent leur métier, leur charge mentale, leur visibilité, parfois leur poste. Le tort des projets IA est de ne pas l’anticiper, et de promettre des gains de productivité sans avoir préparé la conversation sur ce que deviennent les heures gagnées. La même mécanique se rejoue côté outils du quotidien : la dérive d’usage des LLM en interne, qu’on a documentée, n’est qu’une autre face du même angle mort. On parle d’outils, on évite de parler d’organisation.
Ce que l'automatisation expose vraiment
Modéliser un process pour l’automatiser, c’est rendre visibles les redondances, les rôles flous et les boucles de validation qui ne valident rien. C’est cette mise à plat politique, plus que la technique, qui fait échouer les projets IA. Les modèles ne ralentissent pas plus que les personnes bien placées qui défendent leur périmètre quand l’organigramme commence à bouger.
Une organisation prête pour l’IA, c’est d’abord une organisation prête à regarder son propre organigramme et à décider ce qui doit en bouger. Les boîtes qui sautent cette étape obtiennent des PoC (Proof of Concept, démonstrateur) qui marchent en isolation et qui ne passent jamais en production. C’est exactement ce qu’on constate aussi sur les déploiements de CRM avec agents IA en contexte opérationnel, où la performance technique de l’agent ne sert à rien si la chaîne commerciale en aval refuse de se laisser réorganiser.
Le DG doit y aller lui-même
Le troisième problème est rarement écrit noir sur blanc dans les rapports stratégiques. Une transformation IA ne se délègue pas entièrement. Un « AI Lead » recruté en CDI, une cellule innovation, un Chief Data Officer rattaché à la DSI, un cabinet de conseil : toutes ces ressources ont une utilité, et les meilleures transformations en mobilisent plusieurs en parallèle. Mais aucune ne remplace l’arbitrage que seul le dirigeant peut rendre quand il faut modifier l’organigramme, réallouer des équipes, redistribuer un budget, neutraliser une chasse gardée.
L’IA est un sujet d’organisation avant d’être un sujet d’outil. Tant qu’elle est traitée comme un sujet d’outil, elle se loge dans la DSI et reste périphérique. Quand Microsoft a facturé 30 dollars par tête pour Copilot Chat et forcé les entreprises à choisir qui méritait l’accès, ce n’est pas un arbitrage de DSI. C’est un arbitrage de direction. Décider qui a accès à l’agent qui rédige les comptes-rendus, qui résume les boîtes mail, qui répond aux clients : c’est décider qui prend de l’avance dans l’organisation. Ce sont des questions de pouvoir et de répartition d’influence. Elles ne se traitent pas en sous-comité.
Concrètement, le patron des entreprises qui réussissent leur transformation IA fait deux choses que les autres ne font pas. Il est présent personnellement aux étapes structurantes du projet, pas seulement en revue de COMEX mais dans les ateliers où l’on dessine la nouvelle organisation. Le format de cette présence dépend du contexte. Certains dirigeants y consacrent une demi-journée hebdomadaire en immersion, d’autres une présence concentrée aux jalons clés avec des décisions rendues vite et clairement. Ce qui compte, c’est la régularité et la lisibilité de l’engagement aux yeux des équipes : si le patron ne montre pas qu’il porte personnellement le sujet, personne autour de lui ne l’investira sérieusement. Et il accepte publiquement de remettre en cause des arbitrages d’organisation qui datent. Sans ces deux gestes, le projet reste un PowerPoint où on a plaqué « GenAI » sur les cases existantes de l’organigramme.
Trois phases qui ne s’inversent pas
Une fois posés ces trois problèmes, le chemin de transformation devient plus clair. Il est plus inconfortable que les calendriers qu’écrivent la plupart des comités de direction, mais sa structure est lisible. Trois phases s’enchaînent, et l’ordre dans lequel elles s’enchaînent compte autant que leur contenu. La durée dépend du périmètre, de la maturité de l’organisation et de l’engagement du dirigeant : certaines entreprises bouclent une transformation utile en quelques mois, d’autres y passent plusieurs années. Ce qui ne change pas, c’est la séquence.
Phase 1 : cartographier l’existant et identifier ce qui n’existait pas avant. Le travail principal est d’archéologie. On démonte un à un les process critiques, on les redessine, on identifie le tiers inutile, le tiers faux, le tiers non documenté. Mais cette phase doit aussi servir à autre chose, et c’est là que se trompent les calendriers trop austères. L’IA rend possibles des process qui n’existaient pas il y a deux ans : analyse systématique des transcripts d’appels commerciaux pour vérifier l’application d’une méthodologie de vente, relecture automatisée des comptes-rendus pour repérer les engagements pris, scoring qualitatif continu des réponses à un cahier des charges. Ces process ne figurent dans aucune cartographie de l’existant, parce qu’ils n’existaient pas. Les essayer pendant la phase 1 est non seulement permis, c’est utile, et c’est ce qui maintient le COMEX engagé pendant que l’archéologie avance. Le piège n’est pas d’expérimenter trop tôt. Le piège, c’est de croire que ces essais constituent la stratégie de transformation. Le livrable de la phase 1 est double : une carte des process tels qu’ils tournent, et une liste d’opportunités neuves à instruire.
Phase 2 : refondre les process. Avant de penser outil, on réécrit les workflows qu’on a cartographiés. On supprime ce qui doit l’être, on fusionne les rôles redondants, on rend explicites les règles métier qui vivaient dans les têtes. C’est la phase la plus politique. C’est aussi celle où l’on commence à voir circuler les premiers fichiers qui ne sont plus l’Excel maintenu en compta depuis cinq ans. Sans cette phase, l’IA va être branchée sur un workflow incohérent et produira un workflow incohérent plus rapide.
Phase 3 : outiller. À ce stade, le choix d’outil devient évident. On sait exactement où l’IA a un effet de levier, quelles données alimenter, quelles décisions automatiser. Les démos qu’on regardait sceptique il y a un an deviennent des intégrations utiles parce que le terrain est prêt. C’est dans cette phase que des cabinets comme EY ont pu basculer 130 000 auditeurs sur une architecture agentique sans interrompre leur production d’audits. Pas en décrétant l’IA en COMEX. En ayant fait le travail des deux phases précédentes.
Trois phases qui ne s'inversent pas
Cartographier l'existant et identifier ce qui n'existait pas avant
Livrable : carte des process tels qu’ils tournent + liste d’opportunités neuves à instruire. Erreur classique : attendre que tout soit propre avant d’expérimenter sur les process neufs.
Refondre les process
Livrable : workflows réécrits, rôles redondants fusionnés, règles métier rendues explicites. Erreur classique : brancher un agent sur un workflow incohérent avant d’avoir tranché les arbitrages d’organisation.
Outiller
Livrable : intégrations IA en production, données alimentées, gouvernance d’usage cadrée. Erreur classique : sauter directement à cette phase avec des PoC qui marchent en isolation mais ne passent jamais à l’échelle.
La plupart des entreprises sautent en phase 3 directement. Elles paient des consultants pour faire tourner des PoC. Trois démos marchent, le COMEX applaudit. Un an plus tard, l’adoption est à 4 %, parce que le sous-jacent n’a pas bougé. Et la conclusion qu’on en tire en interne est presque toujours fausse : « l’IA n’est pas mature ». Ce n’est pas l’IA qui n’est pas mature. C’est l’organisation.
Cinq symptômes qui ne trompent pas
Reconnaître que son organisation n’est pas prête pour l’IA est plus utile que de prétendre l’être. Cinq signaux suffisent à poser le diagnostic.
Un, vous parlez d’IA en COMEX sans avoir lu votre cartographie des process. Si personne autour de la table ne sait restituer le déroulé de bout en bout d’un workflow critique, le projet IA n’est pas un projet. C’est une intention.
Deux, votre « AI Lead » rapporte à un directeur qui n’a pas de mandat sur l’organisation. S’il rend compte à la DSI ou à une cellule innovation, il pourra livrer des PoC. Il ne pourra pas modifier l’organigramme. Sans mandat sur l’organisation, l’AI Lead est un sponsor d’outils.
Trois, vous comptez sur des PoC « pour voir ». Le PoC est utile pour valider une faisabilité technique. Jamais pour décider d’une stratégie. Si vous attendez le succès d’un démonstrateur isolé pour arbitrer la transformation, vous repoussez la vraie décision.
Quatre, vous pensez que l’IA va rendre vos Excels inutiles sans toucher aux process qu’ils décrivent. L’IA ne rend pas un Excel inutile. Elle révèle ce que cet Excel cachait. Si les process ne sont pas redessinés, l’IA va automatiser le désordre.
Cinq, vous attendez le ROI avant d’investir dans la cartographie. Inversion classique et coûteuse : la cartographie est précisément ce qui rend le ROI mesurable. Sans elle, les indicateurs disponibles (temps perçu gagné, satisfaction utilisateur déclarée) ne suffisent jamais à justifier le budget de la phase suivante.
Trois signaux cochés sur cinq, l’organisation n’est pas prête. Ce n’est pas un drame, c’est un point de départ.
Ce qu’on fait quand on veut vraiment y aller
La sortie n’est ni mystérieuse ni propriétaire. Elle se résume à trois engagements concrets pris ensemble par la direction.
D’abord, nommer un sponsor exécutif unique avec mandat explicite sur l’organisation. Pas un AI Lead rattaché à la DSI, pas une cellule innovation, pas un directeur métier dilué entre dix sujets. Une personne au comité exécutif, désignée publiquement, avec autorité pour arbitrer les conflits d’organigramme que le projet va faire émerger. Sans cette désignation, l’élan retombe au premier obstacle politique.
Ensuite, démarrer par un audit cadré de quatre à six semaines sur un process critique unique. Pas trois, pas tout le périmètre. Un. On en sort une carte de l’existant et une liste de chantiers de refonte priorisés. Si la direction n’accepte pas le diagnostic posé par cet audit, le projet IA s’arrête là. C’est honnête, et plus économique que de continuer.
Enfin, refuser de signer un projet d’industrialisation à l’échelle tant que la cartographie n’a pas été faite sur le périmètre concerné. La nuance compte. Les essais ciblés sur des process neufs (suivi post-appel, analyse de transcripts, scoring qualitatif des livrables) peuvent et doivent démarrer en parallèle de la cartographie : ils alimentent le diagnostic et créent l’appétit. Mais l’industrialisation d’un agent qui touche une chaîne métier établie n’a aucune raison de partir avant que cette chaîne soit cartographiée. Cette règle écarte l’essentiel des erreurs. Elle force aussi les cabinets et les éditeurs à ajuster leurs propositions, ce qui éclaircit beaucoup d’arbitrages.
Une fois ce socle posé, le choix d’outil devient secondaire. Le marché propose cinq solutions sérieuses pour un usage professionnel, elles sont toutes correctes, et la différence entre une bonne implémentation Claude et une bonne implémentation Mistral pèse moins lourd que la différence entre une organisation qui a fait son travail et une organisation qui ne l’a pas fait. C’est par là que ça commence. Pas par l’outil.








