Pourquoi un projet IA réussi commence par vos processus, pas par l'outil

Il y a un scénario qui revient régulièrement chez les dirigeants de TPE/PME que je croise. Plusieurs milliers d'euros investis dans un agent IA pour automatiser une tâche qui pèse lourd : la qualification de devis, la relance de factures, le tri des mails entrants. Six mois plus tard, l'outil tourne, l'équipe l'utilise de moins en moins, les résultats ne sont pas au rendez-vous. Et la question finit toujours par tomber : "Est-ce que l'IA fonctionne vraiment ?"

L'outil fonctionne. C'est le processus qu'il automatise qui n'existe pas vraiment.

Personne dans l'entreprise n'a pris le temps de cartographier ce qui se passe réellement sur le terrain. Les exceptions, les "on fait comme ça parce que c'est plus simple", les contournements liés à un client ou un fournisseur historique. L'IA apprend une version idéalisée du processus, celle qui est présentée en réunion. La réalité est ailleurs.

C'est l'erreur la plus coûteuse que je vois aujourd'hui chez les TPE/PME qui se lancent dans l'IA. Et c'est aussi la plus invisible : elle ne se voit ni dans la facture, ni dans la démo de l'outil. Elle se voit six mois plus tard, dans les résultats.

L'automatisation n'invente rien, elle accélère ce qui existe

Une étude du Project NANDA (MIT Media Lab) publiée en juillet 2025¹ a fait beaucoup de bruit dans le secteur : 95 % des projets d'IA générative déployés en entreprise ne génèrent aucun impact mesurable sur le compte de résultat.

95 %. Ce chiffre est tellement gros qu'on est tenté de le mettre de côté. Pourtant, quand on creuse, il ne dit pas que l'IA ne marche pas. Il dit que la plupart des entreprises échouent à transformer ses capacités en valeur réelle. La nuance compte.

Ce que ces projets ratés ont presque toujours en commun : ils ont automatisé un processus que l'entreprise ne comprenait pas elle-même. Le principe est simple, presque caricatural. Une automatisation prend des entrées, applique des règles, produit des sorties. Si les règles sont floues, les sorties seront floues. Si les entrées varient, les sorties dérailleront. Et plus l'outil est rapide, plus l'erreur se diffuse vite.

Un processus mal défini automatisé ne donne pas un processus efficace. Il donne du flou produit en série.

J'ai vu ça dans tous les secteurs où j'ai travaillé pendant 15 ans : distribution, retail, industrie, services. Le pattern est identique. Plus l'organisation est petite et plus les processus sont implicites, parce qu'ils tiennent dans la tête de deux ou trois personnes. C'est ce qui rend les TPE/PME particulièrement exposées à l'erreur.

Pourquoi les projets échouent : ce n'est presque jamais la technique

Quand un projet IA déraille, la première question qu'on entend est toujours technique. "L'outil n'est pas assez bon", "il faut un meilleur modèle", "Claude (ou son équivalent) ne comprend pas notre métier". C'est presque toujours faux.

Gartner anticipait dès juillet 2024 qu'au moins 30 % des projets d'IA générative seraient abandonnés après leur preuve de concept d'ici fin 2025². Les causes pointées par le cabinet : qualité de données insuffisante et valeur business mal cadrée en amont. Traduction concrète : on a choisi l'outil avant d'avoir compris le problème, et la facture est arrivée quelques mois plus tard.

Côté français, le constat est cohérent. Le baromètre Bpifrance Le Lab publié en juin 2025³ montre que 43 % des PME et ETI françaises n'analysent pas leurs données pour piloter leur activité. Sans cette fondation, l'IA arrive sur un terrain qu'on ne mesure pas, et les projets partent du résultat espéré (« automatiser les devis »), pas de l'état des lieux.

McKinsey, dans son rapport The State of AI 2025⁴, arrive à la même conclusion par les chiffres : 55 % des entreprises qui tirent un véritable impact financier de l'IA ont fondamentalement remanié leurs processus au moment du déploiement, soit près de trois fois plus que les autres.

Le pattern est clair, à toutes les tailles d'entreprise. Le facteur de succès numéro un n'est pas le choix de la techno. C'est la qualité de la connaissance métier que l'entreprise a d'elle-même.

Le processus réel n'est jamais le processus officiel

Voici l'angle mort que la plupart des projets ratent. Dans une entreprise, il existe trois versions de chaque processus, et elles ne coïncident jamais parfaitement :

1. Le processus documenté. Celui qui figure dans le manuel qualité, la procédure ISO, le tableau Notion. Précis, propre, périmé.
2. Le processus déclaré. Celui que les équipes décrivent en réunion quand on leur demande comment elles travaillent. Légèrement embelli, simplifié pour la conversation.
3. Le processus exécuté. Celui qu'on observe sur le terrain en passant une demi-journée à côté de la personne qui le fait. Avec ses exceptions, ses raccourcis, ses contournements.

Un exemple concret. J'ai accompagné un bureau d'études en environnement de l'Ouest qui voulait automatiser la phase amont de ses rapports : la collecte de données réglementaires sur chaque parcelle étudiée. Sur le papier, le processus tenait en une phrase. Interroger 8 portails publics, récupérer les données, les coller dans le rapport. Une équipe technique aurait pu construire ça en deux semaines avec un outil générique.

En passant du temps avec les ingénieurs sur des dossiers réels, j'ai vu autre chose. Ils ne se contentaient pas de lire les données brutes. Ils calculaient la distance entre la parcelle et le cours d'eau le plus proche pour qualifier l'hydrographie. Ils positionnaient la propriété par rapport à l'église du village pour la description terrain. Ils croisaient les retours de plusieurs portails pour produire un libellé géologique cohérent. Ils rédigeaient à la main des paragraphes structurés dans un format précis que le client final attendait dans le rapport.

Aucune de ces subtilités n'était documentée nulle part. Aucune n'apparaissait dans la "phrase" qui décrivait le processus. Toutes étaient indispensables pour que le résultat soit utilisable. Automatiser la seule version documentée aurait produit un outil techniquement fonctionnel et pratiquement inutile, dans lequel les ingénieurs auraient continué à reprendre les données à la main pour faire leur vrai travail. Le cas complet est détaillé ici.

C'est ça, ne pas connaître son processus. Ce n'est pas ignorer qu'on consulte des portails publics ou qu'on relance des impayés. C'est ne pas voir tous les calculs, les croisements et les mises en forme implicites dans lesquels l'expertise humaine se cache.

Ce que « connaître le processus » veut vraiment dire

Quand je parle de cartographier un processus avec un dirigeant, je vois souvent la même crispation. Il imagine un cabinet qui débarque avec un cahier des charges de 80 pages, six semaines d'ateliers, et une facture à cinq chiffres. Ce n'est pas ça.

Connaître un processus, au sens où il faut le connaître pour l'automatiser proprement, ça veut dire répondre à six questions simples :

• Qui fait quoi ? Pas le titre du poste : la personne réelle, et celle qui prend le relais quand elle est absente.
• Quand ? Le déclencheur exact. Pas « quand on reçoit la commande », mais « quand le mail arrive dans la boîte commerce avec PDF en pièce jointe ».
• Avec quelle donnée ? Toutes les entrées nécessaires, y compris celles qu'on regarde « à l'œil » sans s'en rendre compte (l'historique du client, le ton du mail, la signature).
• Quelles exceptions ? Les cas qui sortent du flux principal et qui sont gérés à la main, même s'ils représentent 10 % du volume.
• Quels cas limites ? Les situations rares mais coûteuses si elles partent mal (un fournisseur en redressement, un client en litige, une commande à cheval sur deux exercices).
• Quel résultat acceptable ? Le critère qui distingue « le travail est fait » de « il faut recommencer ».

Ces six questions ne se répondent pas en salle de réunion. Elles se répondent en allant voir. Une demi-journée passée à côté de la personne qui exécute le processus vaut plus que quarante pages de spécifications rédigées sans elle.

C'est exactement la posture que j'ai adoptée chez Yono Consulting avant de proposer la moindre automatisation. Pas par méthode imposée : par expérience accumulée sur des projets qui ont coûté cher quand cette étape a été sautée.

Concrètement : par où commencer avant d'automatiser

Si vous êtes dirigeant et que vous envisagez votre premier projet d'automatisation ou d'IA, voici la méthode minimale que je recommande, avant même de regarder le moindre outil.

1. Observer le terrain

Choisissez le processus que vous voulez automatiser. Passez deux à trois heures à côté de la personne qui le fait aujourd'hui. Pas pour la juger, pas pour optimiser. Pour voir. Vous serez surpris de découvrir des étapes invisibles depuis votre bureau.

2. Lister les exceptions

Sur une feuille de papier, notez toutes les variantes du processus standard. « Pour ce client on fait autrement parce que… », « quand c'est en fin de mois on inverse l'ordre… », « si le montant dépasse X je préviens d'abord le dirigeant ». Tout. Même les « ce n'est pas grand-chose ».

3. Identifier le cas à fort volume et faible complexité

L'objectif d'une première automatisation n'est pas de tout couvrir. C'est de gagner du temps là où c'est facile, et de laisser l'humain sur les exceptions. Cherchez la catégorie de cas qui représente le plus gros volume avec le moins de variantes. C'est par là qu'il faut commencer.

4. Mesurer l'existant

Combien de temps prend ce processus aujourd'hui, sur ce volume précis ? Combien d'erreurs ? Combien de relances clients liées à ces erreurs ? Sans cette mesure de départ, vous ne pourrez jamais prouver le gain. Et sans preuve de gain, le projet ne tiendra pas dans la durée.

Ces quatre étapes prennent une à deux journées de travail réparties sur deux semaines. Elles transforment un projet à 95 % de risque d'échec en projet maîtrisé. Le coût d'opportunité de les sauter est presque toujours supérieur à leur coût d'exécution.

La technique est mûre. Le métier reste à formaliser

L'IA et l'automatisation ont massivement progressé en deux ans. Les modèles de langage actuels comprennent un contexte métier, lisent des PDF complexes, dialoguent avec des outils existants. La technique n'est plus le goulot d'étranglement pour les TPE/PME. Le marché regorge d'outils accessibles, paramétrables, raisonnablement prix.

Le goulot, c'est la connaissance que l'entreprise a d'elle-même. C'est ce que les chiffres du MIT, de Gartner, de Bpifrance et de McKinsey disent tous, sous des angles différents : les organisations qui réussissent ne sont pas celles qui ont le meilleur outil, ce sont celles qui ont passé le temps de comprendre ce qu'elles voulaient automatiser.

Bonne nouvelle pour les TPE/PME : c'est une compétence qui se travaille en interne, sans budget colossal, avec un peu de méthode. Et c'est précisément le rôle d'un accompagnement extérieur sérieux. Pas vendre un outil, mais aider à formaliser le terrain assez clairement pour que l'outil produise de la valeur.

C'est la conviction sur laquelle j'ai construit Yono Consulting après quinze ans passés à mener des projets de transformation digitale dans des organisations de toutes tailles. La technique change tous les six mois. Le besoin de comprendre son métier avant de l'automatiser, lui, ne bouge pas.

30 minutes d'échange, sans engagement, pour identifier un processus candidat dans votre entreprise et vérifier ensemble qu'il est prêt à être automatisé. C'est souvent là que les choses sérieuses commencent.

Notre page services détaille notre méthode d'accompagnement, et vous pouvez aussi consulter qui je suis si vous voulez en savoir plus sur notre approche.

Sources

1. MIT Media Lab, Project NANDA, The GenAI Divide: State of AI in Business 2025 (juillet 2025)
2. Gartner, Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025
3. Bpifrance Le Lab, L'IA dans les PME et ETI françaises : une révolution tranquille (juin 2025)
4. McKinsey & Company, The State of AI: How organizations are rewiring to capture value (mars 2025)