Dans la première partie, j'ai séparé deux approches qu'on confond souvent lorsqu'on parle d'utiliser l'IA.

Utiliser l'IA, c'est la laisser dans le périmètre d'un logiciel — qu'on la sollicite à la main ou qu'elle tourne toute seule. Intégrer l'IA, c'est lui donner pour périmètre l'organisation : elle lit là où vos données vivent, elle écrit là où les réponses sont requises. Et j'ai proposé une grille pour vous permettre de savoir où vous en êtes.

Reste malgré tout une objection qui revient souvent :

Si l'outil IA utilisé fait déjà gagner du temps même s'il est isolé, pourquoi payer plus cher pour intégrer l'IA ?

La réponse est simple : parce que les deux approches ne produisent pas des gains de même nature. Et parce que l'écart entre les deux ne se voit pas au moment où vous décidez, mais après. Avec un coût non négigeable.

Les coûts qu'utiliser l'IA vous fait payer — sans les afficher

Quand un dirigeant calcule le ROI de son outil IA, il compte les minutes économisées directement sur la tâche concernée. Cependant, il ne compte pas cinq coûts structurels — invisibles dans le calcul, bien réels dans le compte de résultat.

Coût #1 - Le travail de plomberie humaine

**Tous les gestes manuels autour de l'outil. **La personne qui copie-colle, vérifie, ressaisit, relit. C'est du temps qui n'apparaît jamais dans le calcul d'économie, parce qu'il était déjà là — et le projet n'a pas eu l'ambition de l'éliminer. Pourtant, il participe de la perte de productivité.

Coût #2 - L'opacité

Ce que l'IA produit n'est pas observable dans les systèmes de pilotage. Les insights ne remontent pas, ils ne sont pas visibles ailleurs que là où ils ont été produits. Les résultats n'alimentent pas d'autres actions. La valeur produite s'évapore dès que la personne qui l'a générée quitte son écran.

Coût #3 - La fragilité du couplage humain

Quand la personne qui utilisait l'outil part, change de poste, ou oublie une étape, le système casse silencieusement. Personne ne sait quand, personne ne sait pourquoi les chiffres ont bougé, pourquoi le résultats sont inexacts. Une utilisation dont la fiabilité repose sur une personne est une dépendance, et un potentiel point de rupture.

Coût #4 - La fragmentation des cas d'usage

Chaque nouveau besoin métier déclenche un nouveau projet IA isolé. Pas d'infrastructure partagée, pas de contexte commun, pas de réutilisation. Au bout de dix-huit mois, vous avez payé trois fois la même plomberie de base et vous gérez trois contrats de maintenance distincts pour des outils qui ne se combinent pas.

Coût #5 - Les synergies transverses perdues

Une organisation n'est pas une somme de tâches autonomes — c'est un réseau de fonctions qui s'alimentent.

Une IA qui n'intègre pas cette réalité produit de la valeur qui qui reste locale.

Le commercial et l'opérationnel ne se rejoignent pas dans le système. L'opérationnel et le financier ne se rejoignent pas dans le système.

Les arbitrages transverses qu'une IA bien intégrée pourrait éclairer en temps réel ne sont jamais disponibles pour les décisions. Ce sont donc autant de gains d'optimisation ou de performance qui sont purement et simplement ignorées.

Ces gains manqués n'apparaissent dans aucun ROI parce que personne ne sait qu'ils existent.

Les gains de l'intégration se combinent — pas ceux de l'usage

C'est ici que les deux approches cessent de se ressembler.

Les gains de l'usage sont plats. Chaque cas d'usage rapporte ce qu'il rapporte, une fois, et s'arrête là.

Le dixième cas d'usage vous coûte à peu près ce que vous a coûté le premier, et vous rapporte à peu près la même chose.

Vous n'êtes pas en train de construire quelque chose. Vous êtes en train d'acheter la même chose dix fois.

Les gains de l'intégration se cumulent, pour trois raisons distinctes.

Raison #1 - Le coût marginal du cas d'usage suivant s'effondre.

La première intégration coûte en infrastructure : la connexion aux systèmes, la gestion des droits, le format des données, la traçabilité, les règles de déclenchement. La deuxième réutilise tout ça. La cinquième se construit sur un socle déjà payé et déjà éprouvé.

Là où l'usage additionne des projets, l'intégration amortit une infrastructure.

Raison #2 - Le contexte s'accumule

Une IA qui écrit dans vos systèmes enrichit la matière que la suivante lira. Ce qu'elle produit devient une donnée d'entrée pour le reste de l'organisation.

En mode usage, la sortie meurt dans une boîte mail : elle a servi une fois, elle ne servira plus jamais.

En mode intégré, chaque exécution augmente le stock de contexte exploitable — et donc la qualité de tout ce qui viendra après.

Raison #3 - Les arbitrages transverses deviennent possibles

Quand le commercial, l'opérationnel et le financier vivent dans le même système, une IA intégrée peut apporter à chaque fonction ou rôle les éléments qu'il n'avait pas ou difficiement auparavant. Une dérive de marge repérée sur un segment client avant la clôture. Une tension de charge détectée pendant qu'on signe encore.

C'est le moment où le gain cesse d'être une économie de temps et devient un avantage de décision et d'action — le seul type de gain qu"un concurrent ne rattrape pas en achetant le même outil que vous.

Il faut ajouter une asymétrie de calendrier, parce que c'est elle qui piège les dirigeants.

Les deux courbes se croisent. À trois mois, l'usage gagne : il est déjà livré, il produit déjà des minutes économisées, il se démontre en réunion.

À dix-huit mois, l'écart est structurel et ne se rattrape plus. Or le dirigeant compare les deux approches au moment de l'achat — c'est-à-dire au seul moment du cycle où l'usage a l'air d'être le meilleur choix.

Pourquoi l'usage est le choix par défaut

L'intégration est la partie la plus longue et la plus chère d'un projet IA. C'est aussi celle qu'on coupe en premier quand on veut livrer vite.

Un prototype en deux semaines n'a jamais le temps de se câbler — il reste dans son périmètre par construction.

La rapidité de livraison et la profondeur d'intégration sont en tension structurelle, et c'est presque toujours la seconde qui cède.

Et ce n'est pas seulement la livraison qui est en cause. L'intégration suppose qu'on ait préalablement compris comment l'organisation travaille — comment ses fonctions s'alimentent, quels sont les flux entre les outils, ce qui doit remonter vers la décision et ce qui doit descendre vers l'exécution.

Ce travail-là demande de la lecture organisationnelle, pas seulement de la maîtrise technique.

La plupart des prestataires font l'inverse : ils proposent des outils sans avoir lu le système organisationnel. C'est précisément pour cette raison que leurs outils ne s'intègrent jamais.

Par où commencer

Trois principes suffisent à ne pas tomber dans le choix par défaut.

1. Choisissez le premier cas d'usage pour son câblage, pas pour son ROI.

Le réflexe est de démarrer par la tâche la plus coûteuse en temps. C'est une erreur de séquence : le premier chantier paie l'infrastructure, il faut donc le choisir pour les connexions qu'il installe — le système où vivent vos données de référence, la gestion des droits, la traçabilité.

Un cas d'usage moyennement rentable qui vous branche sur votre ERP vaut mieux qu'un cas très rentable qui ne vous branche sur rien. Le deuxième et le troisième toucheront leur gain sans repayer le socle.

2. Exigez le schéma de flux avant la démo

Un prestataire qui a lu votre organisation sait dire, avant d'avoir écrit une ligne de code, ce que l'outil lira, où il écrira, sur quel événement il se déclenchera et qui il notifiera. S'il propose la démonstration d'abord et l'architecture ensuite, l'ordre de ses priorités est déjà votre réponse.

3. Décidez du retour dès le cadrage

C'est la partie qu'on coupe systématiquement, parce qu'elle ne se voit pas dans une démonstration : la sortie qui s'écrit dans le dossier, l'information qui remonte au pilotage, l'événement qui déclenche la suite.

Si personne n'a écrit noir sur blanc où atterrit ce que l'IA produit, ça atterrira dans une boîte mail.- ou un thread Slack.

Et une contrainte de calendrier, qui vaut pour les trois : rien de tout cela ne se décide après. On ne rattrape pas l'intégration d'un outil livré isolé — on le repaie.

Ce qu'il faut retenir

Une IA qu'on utilise est une calculatrice intelligente. Utile, limitée, et payée à nouveau à chaque nouveau besoin.

Une IA qu'on intègre — qui vit dans vos systèmes, qui partage son infrastructure avec d'autres usages, qui reconnaît le réseau des fonctions qu'elle sert — devient une capacité organisationnelle.

La première vous fait gagner des minutes. La seconde change ce que votre entreprise est capable de réaliser.

La différence n'est pas dans l'intelligence du modèle. Elle est dans la plomberie qu'on a accepté — ou refusé — de construire.

Avant votre prochain projet IA

Lire l'organisation avant de proposer l'outil, c'est le travail que je fais : ce qui circule entre vos systèmes, ce qui doit remonter jusqu'aux décisions, ce à quoi le premier chantier doit vous brancher. Si vous cadrez un projet IA, ou si vous cherchez pourquoi celui que vous avez n'a rien composé — c'est ce que fait LEAD. Stratégie et implémentation, du cadrage à la livraison.

Et si vous voulez voir à quoi ressemble un gain qui se compose : myVP est le Chief of Staff IA construit sur ce principe — chaque exécution réécrit dans les systèmes que la suivante ira lire, si bien que le contexte qu'il détient grandit au lieu de repartir de zéro.