Sept erreurs reviennent dans les premiers projets d’automatisation IA en PME. Voici les cinq plus fréquentes, toutes décidées au cadrage, avant la première ligne de code.
- Vouloir tout automatiser d’un coup. Le périmètre gonfle en trois réunions, et quand cinq processus changent en même temps, plus personne ne sait lequel a produit le résultat.
- Lancer sans avoir mesuré l’existant. C’est la seule erreur irrattrapable : une fois le processus modifié, la situation d’avant n’existe plus, et le gain reste une conviction au lieu d’une démonstration.
- Partir de l’outil et non du problème métier. On choisit une plateforme impressionnante, puis on cherche quoi lui faire faire. Les compromis de cet ordre inversé se paient pendant des années.
- Ne définir aucun critère d’arrêt. Sans seuil écrit avant le lancement, personne n’ose interrompre un projet déjà financé : il ne se termine jamais, il s’éteint.
- Oublier les équipes qui vont l’utiliser. Compétences internes manquantes et résistance au changement pèsent, à elles deux, plus lourd que tous les blocages techniques relevés en PME.
Le projet n’a pas planté. Personne n’est capable de dire s’il a marché. C’est le paradoxe le plus fréquent des premières automatisations en PME, et le plus coûteux.
Le scénario se répète : un dirigeant voit une démonstration convaincante, valide un budget, et l’équipe déploie un premier processus automatisé en quelques semaines. Six mois plus tard, l’outil tourne, deux personnes sur cinq s’en servent, et la question « qu’est-ce que ça nous a rapporté ? » reste sans réponse.
Rien n’a échoué au sens technique. Ce qui manque se décidait bien avant : le périmètre, la mesure de départ, le seuil à partir duquel on aurait dit oui ou non. Voici les sept erreurs qui coûtent le plus cher et la séquence de cadrage qui les neutralise.
Pourquoi un premier projet d'automatisation IA échoue-t-il rarement pour des raisons techniques ?
Trois chiffres circulent en boucle dans les comités de direction : 95 %, 30 %, 42 %. Ils servent à effrayer et sont presque toujours mal cités. Une agence IA qui accompagne un premier projet passe une bonne partie de sa première réunion à les remettre à l’endroit.
Ce que ces trois études mesurent réellement
La nuance n’est pas un détail méthodologique : elle change la conclusion à en tirer pour votre entreprise.
| Source | Chiffre | Ce qu’il mesure réellement | Le contresens fréquent |
|---|---|---|---|
| MIT NANDA, The GenAI Divide (2025) | 95 % | Des pilotes d’IA générative étudiés n’ont montré aucun impact mesurable sur le compte de résultat, sur six mois. Plus de 300 déploiements publics, 52 entretiens, 153 réponses de dirigeants. | « 95 % des projets d’IA échouent ». Faux : ce sont des pilotes d’IA générative, et l’absence d’impact mesuré à six mois n’est pas un échec. |
| Gartner, prévisions 2025-2026 | Environ 30 % | Prévision d’abandon après la preuve de concept, sur les projets d’IA générative. | « 30 % des projets échouent ». C’est un abandon à un stade précis, le passage à la production. |
| S&P Global, enquête 2025 | 42 %, contre 17 % en 2024 | Part des entreprises interrogées ayant abandonné la majorité de leurs initiatives d’IA. Plus de 1 000 entreprises, Amérique du Nord et Europe. | « 42 % des projets échouent ». L’unité mesurée est l’entreprise, pas le projet. |
Le vrai enseignement est plus dérangeant : un pilote lancé sans critère de succès défini à l’avance ne peut jamais être déclaré réussi, quelle que soit sa qualité technique. Le MIT observe sur six mois, sur un échantillon restreint, et cette limite mérite d’être dite plutôt que masquée.
D’où viennent les échecs réellement constatés en PME ?
Le baromètre IA PME publié par Denis Atlan, qui porte sur 54 échecs analysés entre 2022 et 2025, donne un taux d’échec observé de 27 % et une répartition des causes. C’est le travail d’un consultant indépendant sur un échantillon limité : un signal de terrain, pas une statistique établie.
- Compétences internes manquantes : 25,7 % des échecs. Personne ne peut reprendre l’outil quand le prestataire s’arrête.
- Blocages techniques à l’intégration : 22,9 %. La démonstration fonctionne, le branchement au système existant coince.
- Budget dépassé : 20,0 %. Au passage en production, jamais au prototype.
- Qualité insuffisante des données : 17,1 %. Les fichiers existent, ils ne sont ni complets ni homogènes.
- Résistance au changement : 17,1 %. L’outil marche, personne ne s’en sert.
Une seule cause sur cinq relève vraiment de la technique. Les quatre autres se décident au cadrage, quand rien n’a encore été construit. C’est le terrain d’un projet d’automatisation IA bien mené, où la méthode pèse plus lourd que l’outillage.
La grille qui tranche le périmètre tient en quatre critères. Volume : 50 à 100 occurrences par mois au minimum, ou une tâche mobilisant plus de 3 heures par semaine. Régularité : au moins 85 % des cas suivant le même schéma, faute de quoi le périmètre est trop instable. Risque : rien de réglementaire ni de fortement financier sans validation humaine. Données : elles doivent déjà exister et être exploitables, sinon ce n'est pas un projet d'automatisation mais un chantier de remise en ordre.
Erreur n° 1 : vouloir tout automatiser d'un coup
C’est l’erreur la plus fréquente, et la plus compréhensible. Une fois la décision prise, la tentation est d’embarquer tout ce qui traîne : facturation, relances, service client, rapports hebdomadaires. Le périmètre gonfle en trois réunions.
Le problème n’est pas l’ambition, c’est l’arithmétique. Plus le périmètre est large, plus les cas particuliers se multiplient, et plus le gain devient impossible à attribuer. Quand cinq processus changent en même temps, personne ne saura lequel a produit le résultat.
- Il dilue la responsabilité : plus aucun métier ne se sent propriétaire du sujet.
- Il retarde la première preuve : six mois pour un verdict flou, au lieu de six semaines pour un résultat net.
- Il rend l’arbitrage impossible : arrêter un projet à quatre volets revient à tout arrêter.
- Il masque les exceptions : les cas hors norme ne se révèlent qu’en production.
La règle tient en une phrase : un premier projet doit être assez petit pour qu’on puisse l’arrêter sans drame, et assez mesurable pour qu’on sache s’il faut l’étendre.
« Personne ne veut écrire le critère d'arrêt, parce que l'écrire, c'est admettre que ça peut ne pas marcher. C'est exactement l'inverse : c'est ce qui autorise à essayer. Sans seuil fixé à l'avance, un projet ne se termine jamais, il s'éteint. Et un projet qui s'éteint ne vous apprend rien, alors qu'un projet arrêté sur un critère clair vous dit précisément quoi changer la fois suivante. »
Avant toute mise en œuvre, établissez votre mesure de référence et faites-la valider par la personne qui exécute le processus aujourd'hui, pas par son responsable. C'est le geste le moins coûteux du projet, et le seul qui rende un gain démontrable plus tard. Sans lui, vous discuterez pendant des mois d'un retour sur investissement que personne ne peut ni prouver ni contester : c'est ce que nous verrouillons en premier dans un audit et conseil IA.
À lire également : Pourquoi tant de projets d'agents IA autonomes échouent-ils avant d'atteindre la production ?
Erreur n° 2 : lancer sans avoir mesuré l'existant
C’est l’erreur la plus silencieuse, et la seule qui soit irrattrapable : une fois le processus modifié, la situation d’avant n’existe plus, et vous ne reconstituerez jamais ce que vous n’avez pas relevé.
L’entreprise se retrouve avec un outil qui fonctionne et aucun moyen de prouver qu’il apporte quelque chose. Le retour sur investissement devient une conviction, pas une démonstration, et le budget suivant se négocie à l’intuition.
Quels indicateurs relever avant de commencer ?
Six mesures suffisent, et se relèvent sur 1 à 2 semaines si le flux est quotidien.
- Le temps moyen par dossier, chronométré et non estimé.
- Le volume traité sur une période donnée, la même avant et après.
- Le taux d’erreur constaté sur ce processus.
- Le délai de traitement, de la réception à la clôture.
- Le coût par traitement, charges comprises.
- Le taux de reprise humaine, les dossiers repassés à la main.
Deux précautions font toute la différence. Comptez exactement de la même manière avant et après, sinon la comparaison ne vaut rien. Et isolez les cas d’exception : c’est là que se creuse l’écart entre la démonstration et le terrain.
Deux angles morts se cumulent en fin de projet et se renforcent l'un l'autre. La maintenance non budgétée, qui transforme une automatisation en dette dès que le prestataire s'éloigne. Le critère d'arrêt jamais écrit, ensuite, qui empêche de constater la dégradation puisque aucun seuil ne permet de la déclarer. Une automatisation abandonnée sans avoir été arrêtée continue de coûter : licences, maintenance, et le processus manuel qui a repris en parallèle sans que personne ne l'annonce.
Erreur n° 3 : partir de l'outil et non du problème métier
Le raisonnement s’inverse toujours de la même façon. On a vu une plateforme, elle est impressionnante, on cherche ensuite quoi lui faire faire. C’est l’ordre inverse de celui qui produit un résultat.
Un outil d’orchestration comme Make ou n8n peut porter la quasi-totalité des premiers projets d’une PME, et un développement sur mesure se justifie sur un flux critique. Aucun des deux ne dit quoi automatiser. Ce choix vient après trois questions.
- Quel problème métier cherchez-vous à réduire ? Un délai, un coût, un taux d’erreur, pas « gagner en productivité ».
- Qui subit ce problème aujourd’hui ? S’il n’y a pas de personne identifiable, il n’y a pas de sujet.
- Qu’est-ce qui changerait, mesurablement, si le problème disparaissait ? C’est la réponse à cette question qui deviendra votre indicateur.
Choisir la technologie avant d’avoir répondu revient à adapter le problème à l’outil. Les compromis se paient pendant des années, en contournements et en tâches manuelles résiduelles que plus personne n’ose remettre en cause.
Erreur n° 4 : choisir le mauvais premier processus
Le premier processus automatisé n’est pas seulement un gain opérationnel : c’est la démonstration qui décidera du reste. Un premier projet raté ferme la porte pour deux ans, même quand les suivants auraient réussi.
Les seuils de la grille présentée plus haut ne sont pas des normes, ce sont des repères de praticiens. Ils servent à écarter les faux bons candidats, évidents en réunion et ingérables à l’usage.
Quels processus écarter d’un premier projet ?
- Les processus rares, sous le seuil de volume.
- Les processus très variables, où plus d’un cas sur six sort du schéma habituel.
- Les processus à fort enjeu réglementaire ou financier sans validation humaine prévue.
- Les processus aux données éparpillées entre plusieurs outils sans référentiel commun : le vrai projet est ailleurs.
Un pilote restreint se construit très bien sur des briques de développement no-code, précisément parce qu’il doit rester peu coûteux à jeter. Reste une question avant de lancer : ce que vous voulez automatiser relève-t-il vraiment de l’IA, ou d’une automatisation classique bien faite ? Beaucoup de premiers projets n’ont besoin d’aucun modèle, et s’en portent mieux.
Pour en savoir plus : Faut-il un agent IA ou une automatisation classique pour votre PME ?
Erreur n° 5 : ne définir aucun critère d'arrêt
Demandez à une entreprise qui lance son premier projet à quel moment elle décidera que ça n’a pas marché. La question n’a presque jamais été posée. C’est ce qui transforme un essai en engagement sans fin.
Un critère d’arrêt n’est pas un aveu de pessimisme, c’est ce qui rend l’essai possible. Sans lui, personne n’ose interrompre un projet où du budget a déjà été engagé, et l’on continue à financer une automatisation dont plus personne n’attend rien.
Quel niveau de fiabilité viser sur un pilote ?
- 70 à 75 % en première semaine de test est un niveau normal, pas un signal d’alerte.
- 85 % minimum avant de généraliser : en dessous, la charge de reprise humaine annule le gain.
- 3 à 6 indicateurs maximum : au-delà, l’attention se dilue.
- 4 à 8 semaines de pilote : assez long pour observer, assez court pour arbitrer.
La règle de pivot se fixe avant le lancement, jamais pendant. Si la fiabilité reste sous 85 % sur le périmètre visé à la fin du pilote, on réduit le périmètre aux cas simples plutôt que de l’élargir. Écrite à l’avance, cette phrase vaut tous les comités de pilotage.
Erreur n° 6 : oublier les équipes qui vont l'utiliser
La résistance au changement représente 17,1 % des échecs relevés dans le baromètre cité plus haut, et les compétences internes manquantes 25,7 %. Ensemble, ces deux causes pèsent plus lourd que tous les blocages techniques réunis.
Le mécanisme est toujours le même. Le projet se décide entre la direction et un prestataire, il est présenté aux équipes une fois construit, et il arrive comme un contrôle déguisé. La question que personne ne pose à voix haute est simple : est-ce que ça remplace mon travail ?
- Associez l’exécutant du processus dès le cadrage : c’est lui qui connaît les exceptions que personne n’a documentées.
- Nommez un relais interne, capable de décrire le fonctionnement et de signaler les dérives, même sans compétence technique.
- Formez sur les cas limites, pas sur l’outil : c’est là que l’humain reste nécessaire dans la boucle.
- Dites ce qui ne change pas, et qui garde la main sur quoi. Le non-dit produit plus de résistance que la mauvaise nouvelle.
Une automatisation que les équipes contournent coûte plus cher qu’une automatisation qui n’existe pas : vous payez l’outil, la maintenance, et le processus manuel qui continue en parallèle. C’est pourquoi l’adhésion des équipes se traite comme un livrable du cadrage, au même titre que les indicateurs, dans une mission d’audit et conseil IA.
Erreur n° 7 : budgéter le prototype et pas la durée
Le coût le plus élevé n’est presque jamais celui du prototype. Il apparaît au passage en production, quand les cas particuliers que personne n’avait comptés doublent la charge d’intégration, puis chaque année sous forme de maintenance.
Un repère cité côté PME situe le budget annuel de maintenance autour de 15 à 20 % de l’investissement initial. Ce n’est pas une norme, mais il suffit à changer un arbitrage : une automatisation sans ligne budgétaire l’année suivante se dégradera en silence.
Reste un poste que personne ne chiffre au départ : la dépendance au prestataire qui a construit l’outil. Elle se traite au contrat, en cinq exigences, et à aucun autre moment.
- La propriété des processus construits, des paramétrages, des scripts et des documentations.
- L’accès direct aux comptes, environnements, connecteurs et clés techniques, sans passer par le prestataire.
- Une documentation à jour : cartographie des flux, intégrations, dépendances, procédure de reprise.
- Une assistance à la migration et un transfert de compétence, avec un volume d’heures défini au contrat.
- Un coût de sortie fixé à l’avance, jamais négocié le jour du départ.
Les ordres de grandeur donnent la mesure de l’enjeu : 2 à 4 heures par processus reconstruit, et 5 à 10 jours-homme pour un parc de 30 à 50 automatisations. Il n’existe aucun outil de transfert universel entre ces plateformes : une migration se fait par reconstruction.
À découvrir absolument : Vos agents IA dépendent-ils trop d’un seul fournisseur d’IA ?
Ce qu'il faut faire à la place : la séquence de cadrage en 7 étapes
Ces sept erreurs ont une propriété commune : elles se neutralisent en amont, dans un ordre qui n’est pas interchangeable. Chaque étape produit l’information dont la suivante a besoin.
- Cartographiez le processus réellement exécuté, exceptions comprises, en observant plutôt qu’en interrogeant.
- Sélectionnez le cas d’usage sur la grille volume, répétitivité, risque, données.
- Mesurez la référence sur 1 à 2 semaines, avec des règles de comptage écrites qui ne bougeront plus.
- Définissez 3 à 6 indicateurs et leurs seuils, dont le seuil de succès et la règle de pivot.
- Construisez un pilote restreint, validation humaine sur les cas sensibles, sur 4 à 8 semaines.
- Mesurez le gain réel exactement comme à l’étape 3, exceptions comptées à part.
- Décidez : industrialiser, réduire aux cas simples, ou arrêter. Les trois issues sont des réussites de méthode.
Combien de temps prend ce cadrage ?
Les quatre premières étapes tiennent en deux à trois semaines pour un processus bien identifié, l’essentiel en observation et en relevé. C’est dérisoire comparé au coût d’un pilote qu’on ne saura pas juger. Voici les sept erreurs et le signal qui permet de les détecter tôt.
| Erreur | Signal d’alerte | Correction |
|---|---|---|
| Tout automatiser d’un coup | Le périmètre s’élargit à chaque réunion | Un seul processus, arrêtable sans drame |
| Lancer sans mesurer l’existant | Les temps de traitement sont cités de mémoire | Six mesures relevées sur 1 à 2 semaines |
| Partir de l’outil | La plateforme est choisie avant le problème | Trois questions métier avant tout choix d’outil |
| Mauvais premier processus | Moins de 50 occurrences par mois, ou 1 cas sur 6 en exception | Appliquer la grille volume, régularité, risque, données |
| Aucun critère d’arrêt | Personne ne sait dire à quel moment on arrête | Seuil de succès et règle de pivot écrits avant |
| Oublier les équipes | Outil présenté une fois construit, usage réel faible | Associer l’exécutant au cadrage, nommer un relais |
| Budgéter le prototype seul | Aucune ligne de maintenance prévue l’année suivante | 15 à 20 % de l’investissement initial par an, et le contrat de réversibilité |
« La question que je pose en premier n'est jamais « qu'est-ce que vous voulez automatiser ? », mais « combien de temps ça vous prend aujourd'hui, exactement ». Neuf fois sur dix, personne ne le sait. Et c'est là que tout se joue : une entreprise qui ne sait pas mesurer son point de départ ne pourra jamais démontrer son gain, quel que soit l'outil qu'elle achète ensuite. »
Obtenez votre devis personnalisé
Pourquoi confier votre premier projet d'automatisation à IA Agency ?
Notre rôle n’est pas d’apporter un outil, c’est de rendre la décision possible. Le travail se fait avant le développement, et tient en trois engagements.
- Nous cartographions le processus réel, exceptions comprises, en observant ceux qui l’exécutent.
- Nous relevons la mesure de référence et fixons avec vous indicateurs, seuils et règle d’arrêt, par écrit, avant la première ligne de code.
- Nous construisons un pilote restreint, dont le seul objectif est de produire un verdict chiffré en quelques semaines.
C’est un travail court, daté, qui se conclut par une décision documentée : industrialiser, réduire ou arrêter. Cette méthode vaut pour l’ensemble des services d’IA Agency, parce qu’un projet qu’on ne sait pas juger est un projet qu’on ne saura pas défendre.
Conclusion
Retenez l’idée plutôt que la liste. Les erreurs qui coûtent le plus cher ne se commettent ni dans le code ni dans le choix de la plateforme : elles se commettent dans les deux semaines qui précèdent, quand on décide du périmètre, de la mesure et du seuil de succès.
Aucune des sept ne demande de compétence technique pour être évitée. Elles demandent seulement d’écrire trois choses avant de commencer : ce qu’on mesure, à partir de quel niveau on considère que ça marche, et à quel moment on arrête. Ces trois phrases valent plus cher que le prototype qu’elles encadrent.
Si vous préparez un premier projet et que ces trois phrases ne sont pas encore écrites, discutons de votre projet avant l’engagement du budget plutôt qu’après.
Par quel processus faut-il commencer quand on n'a jamais rien automatisé ?
Commencez par un processus répétitif, à fort volume et à faible risque : au moins 50 à 100 occurrences par mois, ou plus de 3 heures par semaine, avec 85 % des cas suivant le même schéma. Écartez le réglementaire et le financier sans validation humaine. Le bon candidat est celui qu’on peut arrêter sans conséquence.
Quel budget prévoir pour un premier projet d'automatisation IA en PME ?
Le montant dépend du processus visé, mais la règle est stable : ne budgétez jamais le seul prototype. Prévoyez le passage en production, les reprises d’intégration liées aux cas particuliers, et une maintenance annuelle de l’ordre de 15 à 20 % de l’investissement initial. C’est ce dernier poste qu’on oublie.
Combien de temps avant de voir les premiers résultats ?
Comptez deux à trois semaines de cadrage, puis un pilote de 4 à 8 semaines. Les premiers résultats exploitables arrivent à la fin du pilote, à condition d’avoir relevé la mesure de référence avant. Sans ce point de départ, vous aurez un outil qui tourne mais rien de démontrable.
Faut-il choisir un outil no-code ou faire développer du sur-mesure ?
La question arrive trop tôt si le problème métier n’est pas formulé. Une plateforme d’orchestration couvre la grande majorité des premiers projets d’une PME et coûte moins cher à abandonner. Le sur-mesure se justifie sur un flux critique. Décidez après avoir défini ce que vous mesurez, jamais avant.
Peut-on lancer un projet d'automatisation sans service informatique ni équipe data ?
Oui, à deux conditions. Le périmètre doit rester restreint et s’appuyer sur des données déjà accessibles. Et un relais interne doit être nommé, même sans compétence technique. L’absence de compétences internes pèse 25,7 % des échecs relevés par le baromètre de Denis Atlan.
Comment mesurer le retour sur investissement d'une automatisation ?
En comparant six mesures relevées avant et après, comptées de la même manière : temps moyen par dossier, volume traité, taux d’erreur, délai de traitement, coût par traitement, taux de reprise humaine. Isolez les cas d’exception. Sans mesure de départ, le retour sur investissement s’estime, il ne se calcule pas.
Combien d'indicateurs faut-il suivre sur un premier projet ?
Entre 3 et 6 au maximum. Au-delà, le pilotage se dilue et plus personne ne consulte le tableau. Ces indicateurs doivent inclure le seuil de succès et la règle de pivot, fixés avant le lancement. Mieux vaut quatre indicateurs regardés chaque semaine que douze consultés une fois.
Que faire si les données de l'entreprise sont incomplètes ou mal tenues ?
Changez de premier processus. La qualité insuffisante des données représente 17,1 % des échecs relevés dans le baromètre IA PME de Denis Atlan, et une remise en ordre n’est pas un projet d’automatisation. Traitez la question des données comme un projet distinct.
Que se passe-t-il si le prestataire disparaît ou change de stratégie ?
Tout dépend du contrat. Cinq exigences vous protègent : la propriété des processus et paramétrages, l’accès direct aux comptes et clés techniques, une documentation à jour, une assistance à la migration avec un volume d’heures défini, et un coût de sortie fixé à l’avance. Comptez 2 à 4 heures par processus à reconstruire.
Faut-il former les équipes, et qui former en priorité ?
Formez d’abord la personne qui exécute le processus aujourd’hui, puis le relais interne désigné. La formation doit porter sur les cas limites et sur ce qui reste sous contrôle humain, pas sur le maniement de l’outil. La résistance au changement pèse 17,1 % des échecs du même baromètre.
Comment éviter d'accumuler des automatisations qui ne communiquent pas entre elles ?
En imposant deux règles dès le premier projet : une documentation à jour des flux et des dépendances, et un point de passage unique pour les données partagées. Un parc de 30 à 50 automatisations non documentées demande 5 à 10 jours-homme pour être reconstruit ailleurs.
À partir de quel volume une tâche mérite-t-elle d'être automatisée ?
Le repère de praticiens situe le seuil à 50 à 100 occurrences par mois, ou à une tâche mobilisant plus de 3 heures par semaine avec des règles stables. En dessous, l’effort de mise en œuvre dépasse le gain. Ce seuil n’est pas une norme absolue, mais un filtre.
Faut-il tout automatiser avec l'IA ?
Non, et c’est même l’erreur la plus fréquente sur un premier projet. Un processus rare, très variable ou à fort enjeu réglementaire sans validation humaine ne doit pas être automatisé en premier. Beaucoup de tâches candidates relèvent d’une automatisation classique, sans aucun modèle, et s’en portent mieux.
Quelles erreurs éviter en automatisant son service client avec l'IA ?
Les mêmes qu’ailleurs, avec un enjeu supplémentaire : le client voit le résultat. Relevez votre délai de traitement et votre taux de reprise humaine avant de commencer, limitez le périmètre aux demandes les plus répétitives, et prévoyez une validation humaine sur les cas sensibles. Visez 85 % de fiabilité avant d’élargir.
Article mis à jour le 24 août 2026.
Ressources et liens utiles
[2] “Prévisions sur l’adoption de l’IA générative en entreprise”, Gartner, 2025-2026
[3] “Enquête sur l’abandon des initiatives d’IA en entreprise”, S&P Global Market Intelligence, 2025
[4] “Intelligence artificielle : recommandations et fiches pratiques”, CNIL, 2026
[5] “Ressources sur la transformation numérique des TPE et PME”, France Num, 2026
[6] “Travaux sur l’adoption de l’IA par les PME et ETI françaises”, Bpifrance Le Lab, 2026
[7] “Baromètre IA PME”, Denis Atlan, 2026 (200 projets B2B déployés en France, janvier 2022 – décembre 2025, dont 54 échecs analysés)
Vous ne savez pas ce que le processus coûte aujourd'hui ?
Un audit qui pose les indicateurs, les seuils et la règle d'arrêt, par écrit, avant tout engagement de budget.
Réserver un audit IA →
