Construire ou Acheter pour l'Automatisation IA des Flux : Quand une Plateforme Suffit et Quand Non

Construire ou acheter : pour l’automatisation IA des workflows, ce n’est pas la bonne première question

Toute évaluation de fournisseurs pour l’automatisation IA des workflows finit par arriver à la même bifurcation : acheter une licence de plateforme et la paramétrer, ou construire quelque chose sur les systèmes que vous utilisez déjà. Les deux camps ont une présentation convaincante. L’éditeur de la plateforme montre une démo qui automatise en un après-midi une version propre et bien formée de votre processus. Le camp du développement montre un schéma de votre architecture réelle, avec des flèches vers une nouvelle boîte. Aucune des deux présentations ne répond à la question qui décide si l’argent sera rentabilisé : quelle part de ce workflow a réellement besoin d’un modèle ?

Cette question a une réponse mesurable, et cette réponse est généralement un petit nombre. Dans le workflow de traitement des commandes d’un industriel européen que SUPALABS a cartographié étape par étape, trois étapes sur onze nécessitaient réellement un modèle. Les huit autres relevaient de l’extraction de données, de la recherche dans des référentiels, de la validation et du routage, un travail que le logiciel classique fait à moindre coût, plus vite, et avec une réponse que vous pourrez reproduire à l’identique demain (données de mission SUPALABS, 2024–2026). Une fois ce chiffre connu pour votre propre processus, la décision entre construire et acheter se prend presque d’elle-même, car une plateforme est tarifée comme si chaque étape était une étape difficile.

Pourquoi la démo de la plateforme fonctionne et le déploiement non

La démo de la plateforme fonctionne parce qu’elle tourne sur le processus documenté. Demandez à une entreprise quelle est la première étape du traitement des commandes et l’on vous répondra « un e-mail arrive ». C’est vrai et inutile. La véritable première étape, ce sont quarante expéditeurs, pas deux identiques, certains avec la commande dans le corps du message, d’autres dans un PDF joint, d’autres encore dans un tableur dont les colonnes changent chaque trimestre, et un gros client qui téléphone et attend du commercial qu’il saisisse la commande. La démo automatise la première version. Le déploiement se heurte à la seconde.

C’est le schéma qui se cache derrière le chiffre du MIT. L’étude NANDA a interrogé 52 dirigeants, sondé 153 responsables et analysé 300 déploiements publics, et conclu que la fracture entre les 5 % qui créent de la valeur et les 95 % qui n’en créent pas ne tient ni aux talents, ni à l’infrastructure, ni à la réglementation. Elle tient à l’absence d’apprentissage, d’intégration et d’adaptation au contexte : le système ne retient pas les retours, ne s’adapte pas au workflow dans lequel on l’a plaqué, et ne connaît pas les exceptions qui font la réalité de ce workflow. Une licence de plateforme ne règle rien de tout cela à elle seule, car l’éditeur n’a jamais vu vos exceptions. Un développement interne non plus, s’il part du même processus documenté que la démo.

La conséquence pratique, c’est que le choix entre acheter et construire compte moins que ce qui le précède : une description écrite de la façon dont le workflow fonctionne réellement, exception par exception, avant tout engagement financier. Nous avons expliqué séparément pourquoi le processus documenté n’est jamais le processus réel ; la décision entre construire et acheter est le moment où cet écart devient coûteux.

Quand acheter une plateforme est la bonne réponse

Les plateformes justifient leur licence dans des conditions bien précises, et il vaut mieux les énoncer clairement que prétendre qu’un développement est toujours préférable. Achetez quand :

• Le workflow est régulier et les données d’entrée sont déjà structurées. Des factures reçues via le système d’échange italien SDI, des tickets issus d’un helpdesk à champs obligatoires, des commandes passées sur un portail B2B au format fixe. Quand les données sont propres dès leur arrivée, le connecteur et le moteur de règles d’une plateforme peuvent porter le travail, et les parties qui relèvent d’un modèle sont assez réduites pour être paramétrées.
• Les connecteurs natifs de la plateforme couvrent les systèmes que vous utilisez réellement. Pas « dispose d’une API », mais « dispose d’un connecteur maintenu pour cette version de l’ERP, ce CRM, cette GED ». C’est dans l’écart entre les deux que s’enlisent la plupart des déploiements.
• Le volume est élevé et la variabilité faible. Dix mille transactions identiques par mois rentabilisent une licence ; deux cents transactions de deux cents formes différentes, non.
• Vous avez besoin de vérifier à moindre coût si l’idée tient. Un mois de licence pour découvrir que le processus n’est pas celui que tout le monde imaginait, c’est une bonne affaire. Le piège est de rester sur la licence une fois que ce mois a répondu à la question.

Utilisée ainsi, une plateforme est autant un instrument de mesure qu’un produit. L’erreur consiste à considérer la licence comme la destination plutôt que comme l’expérience.

Quand construire est la bonne réponse

Construisez quand les exceptions sont le processus. Cela ressemble à un slogan, alors voici le test. Asseyez-vous une journée à côté de la personne qui fait tourner le workflow et notez chaque fois que le chemin documenté n’est pas celui qui est suivi : le client qui envoie ses commandes sous forme de photo d’une note manuscrite, la facture fournisseur qui renvoie à un numéro de bon de commande inexistant, la validation qui part chez un autre manager le vendredi parce que le responsable habituel est en déplacement. Comptez-les. S’il y en a une poignée, la gestion des exceptions d’une plateforme les absorbera. S’il y en a des dizaines, et que chacune obéit à une règle qui n’existe que dans la tête de quelqu’un, vous êtes face à un développement, car le travail ne consiste pas à automatiser le processus : il consiste à mettre le processus par écrit pour la première fois.

La seconde condition d’un développement, c’est un système que vous comptez conserver. Les plateformes arrivent souvent avec une migration implicite : déplacez les données ici, faites passer le workflow par nous, laissez-nous devenir le système de référence pour cette partie de l’activité. Pour une entreprise dont l’ERP ou le gestionale gère la facturation, la production et la paie depuis quinze ans, ce n’est pas une fonctionnalité. C’est le plus grand risque de carrière qu’un responsable des opérations ou de l’informatique puisse prendre, et ce n’est presque jamais ce que le problème exige. Un développement construit sur les systèmes existants, via leurs interfaces, laisse le système de référence là où il est et ajoute à côté les étapes manquantes. Nous prenons cet engagement par écrit au démarrage de chaque mission, car la question « cela veut-il dire remplacer notre logiciel ? » est la première que pose un DSI, et celle que les fournisseurs esquivent le plus souvent.

Le chiffre qui tranche : le ratio de déterminisme

Voici le chiffre que les fournisseurs des deux camps préfèrent ne pas calculer, parce qu’il fragilise les deux présentations. Prenez le workflow, listez ses étapes et classez chacune comme code déterministe, jugement d’un modèle ou décision qui reste entre les mains d’une personne. La part des étapes déterministes est le ratio de déterminisme, et il est généralement élevé. Dans le traitement des commandes de l’industriel mentionné plus haut, il était de huit sur onze. Dans un processus quote-to-cash à cinq passages de relais, il était plus élevé. Dans le conseil à forte composante de recherche, il est plus faible, car la matière première est du texte et le modèle rédige l’essentiel ; SUPALABS y a mesuré une accélération de 30–50 % des délais de production des livrables, concentrée sur la recherche et le premier jet (données de mission SUPALABS, 2024–2026).

Pourquoi ce ratio décide-t-il entre construire et acheter ? Parce qu’une plateforme est tarifée pour les étapes difficiles. La licence, le coût par utilisateur, le palier d’usage : tout suppose que le modèle fait le travail. Quand le modèle réalise trois étapes sur onze, vous payez le prix d’un modèle pour les huit autres, qui sont des recherches dans des référentiels et des validations qu’une intégration bien construite réalise pour le coût d’un serveur. À l’inverse, quand le ratio est faible et que la plupart des étapes exigent réellement du jugement, une plateforme dotée d’outils d’évaluation et de supervision matures peut être le moyen le moins coûteux d’y parvenir, à condition que ses connecteurs atteignent vos systèmes.

Le ratio est aussi un indicateur de gouvernance. Chaque étape tenue à l’écart du modèle est une étape que l’on peut présenter à un auditeur comme une règle plutôt que défendre comme un échantillon. Pour une entreprise qui devra un jour expliquer une décision automatisée à un régulateur, à un directeur des travaux ou à l’équipe de due diligence d’un acquéreur, ce n’est pas une préférence d’ingénieur. C’est la différence entre un journal des décisions et un haussement d’épaules.

Ce qu’un développement doit vous remettre pour que vous ne soyez captif ni d’un côté ni de l’autre

L’objection honnête au développement est une dépendance d’un autre type : la dépendance envers les personnes qui l’ont construit. Cette objection est fondée quand le développement est livré comme une boîte noire. Elle ne l’est pas quand il est livré avec les documents qui le rendent inspectable. Un développement qui vaut la peine d’être acheté s’accompagne d’un Registre des exceptions (chaque écart réel par rapport au processus documenté, sa fréquence, la personne qui l’absorbe), d’une Carte des frontières IA (la classification étape par étape qui a produit le ratio de déterminisme), d’une Suite d’évaluation avec un jeu de données de référence et un rapport mensuel de précision, et d’un Journal des décisions qu’un responsable conformité peut ouvrir sans demander l’aide d’un ingénieur. Ces quatre livrables, plus un engagement écrit de ne pas remplacer les systèmes que vous utilisez, constituent les cinq livrables que la méthode SUPALABS produit à chaque mission, et c’est grâce à eux qu’un développement peut être arrêté sans être perdu : le système tourne dans vos comptes, le jeu de données de référence reste chez vous, et la seule chose qui s’arrête avec le service, c’est le rapport mensuel.

Demandez ces documents, nommément, à tout partenaire de développement avant de signer. Demandez à tout éditeur de plateforme comment vous pourriez les produire depuis son produit. Les réponses vous en apprendront plus que les deux présentations.

Une règle d’ordonnancement pour l’évaluation

Si le choix est réellement ouvert, voici l’ordre des opérations le moins coûteux. D’abord, cartographiez le workflow avec celles et ceux qui le font tourner, assez longtemps pour produire le Registre des exceptions et la Carte des frontières. Cinq jours suffisent pour un workflow ; un trimestre de découverte n’est pas nécessaire, et c’est généralement le signe que le partenaire facture du temps plutôt qu’il ne trouve des réponses. Ensuite, lisez le ratio de déterminisme sur la carte. Enfin, si le ratio est élevé et que les systèmes sont de ceux que vous conserverez, construisez sur ces systèmes, à prix fixe, avec un périmètre défini à partir de la carte plutôt que d’une estimation au jugé. Si le ratio est faible, que les données d’entrée sont structurées et que les connecteurs d’une plateforme atteignent votre architecture, achetez la licence pour un mois et laissez la même carte vous dire si la plateforme a résisté aux exceptions. Dans les deux cas, la carte est l’actif, et c’est la seule chose qu’aucune des deux présentations ne proposait.

L’enquête de BCG de juillet 2026 menée auprès de 152 PDG d’entreprises réalisant au moins 500 M$ de chiffre d’affaires montre que deux tiers d’entre elles mènent des pilotes IA et que seules 26 % ont intégré l’IA dans une transformation plus large. C’est le segment du marché qui a le budget pour acheter n’importe quelle plateforme et les effectifs pour construire tout ce qu’il veut, et il est pourtant bloqué. La contrainte n’est pas la décision d’achat. C’est que personne n’a mis par écrit la façon dont le travail fonctionne réellement avant de passer à l’action.

Sources & références