Comment intégrer l’IA dans des systèmes existants

L’IA passe rarement en production sur un terrain vierge. Elle atterrit attachée à un CRM acheté en 2017, à un système d’identité que personne ne maîtrise totalement, à un ERP que l’organisation ne peut pas se permettre de casser, et à un workflow dont l’équipe a des années de mémoire. Le modèle est la partie facile du projet. Presque tout ce qui décide si la fonctionnalité IA vit réellement en production plus de six mois se joue côté intégration : comment elle est appelée, par quel utilisateur, avec quelles permissions, comment les données entrent et sortent, ce qui se passe quand elle est lente, ce qui se passe quand elle se trompe.

Cet article est consacré à ce versant du travail. Il suppose que le cas d’usage a déjà passé la sélection, que la stratégie est en place, et que la checklist de préparation a été exécutée. La question maintenant est celle qui est rarement bien traitée dans les présentations : comment cette fonctionnalité IA s’insère-t-elle dans la stack existante sans devenir un système parallèle que l’organisation devra maintenir éternellement, et sans casser les systèmes qui marchent déjà.

La plupart des intégrations IA finissent par ressembler à l’un des quatre schémas reconnaissables. Choisir le bon tôt évite beaucoup de refonte coûteuse.

Le premier schéma, c’est l’IA comme service back-office appelé par les systèmes existants. Le CRM, l’outil de gestion de dossiers ou le helpdesk appelle un endpoint IA, reçoit une réponse (un brouillon, une classification, un résumé), et la présente à l’utilisateur dans l’interface existante. L’utilisateur ne voit jamais une « application IA » séparée. C’est l’intégration la moins coûteuse en friction, et c’est généralement le bon schéma de départ, parce que l’adoption se cale sur l’outil existant.

Le deuxième, c’est l’IA comme étape de workflow dans un orchestrateur. Le moteur de workflow existant (un outil BPM, une plateforme d’intégration, un orchestrateur type Temporal ou Airflow) appelle l’IA comme une étape parmi d’autres, avec des entrées, des sorties, des retries et des timeouts explicites. C’est le bon schéma quand l’IA s’insère dans un processus multi-étapes où certaines étapes sont déterministes et d’autres probabilistes.

Le troisième, c’est l’IA comme application utilisateur séparée qui lit et écrit dans les systèmes existants via des APIs. Plus de friction (un nouvel outil signifie une nouvelle formation, de nouvelles permissions, un nouveau monitoring), mais parfois la bonne réponse quand le workflow lui-même est repensé, et pas seulement augmenté.

Le quatrième, c’est l’IA embarquée dans un système fournisseur déjà en production. De nombreux éditeurs SaaS poussent désormais des fonctionnalités IA à l’intérieur de leur propre plateforme. La question d’intégration devient alors une question de configuration et de gouvernance (quelles données peuvent transiter vers le modèle du fournisseur, à quelles conditions) plutôt qu’une question de construction. Ce schéma est rapide à adopter et lent à défaire, donc la réponse contractuelle et de résidence des données compte autant que la réponse technique.

Le mauvais réflexe est de choisir le schéma en fonction de ce qui est à la mode. Le bon réflexe est de le choisir en fonction de l’endroit où le travail vit réellement, de l’endroit où l’utilisateur est déjà, et de ce que l’organisation pourra maintenir dans un an.

Un modèle qui tourne dans une démo fournisseur n’a aucune des contraintes qu’un modèle en production doit satisfaire. Cinq de ces contraintes décident de l’essentiel de la conception d’intégration.

Identité et accès : qui a le droit d’appeler l’IA, pour le compte de qui, avec quel périmètre de données. L’intégration doit passer par le même SSO et le même modèle d’autorisation que le reste de la stack utilise. Contourner cela avec un compte de service qui « peut tout faire » est la manière dont des fuites de données deviennent des titres de presse plus tard.

Résidence des données et flux contractuel : où les données vont quand l’IA est appelée. Beaucoup de modèles tournent dans une région qui ne correspond pas aux engagements réglementaires de l’organisation. C’est une contrainte sur le modèle qui peut être utilisé du tout pour un workflow donné, pas un détail à régler après le lancement. Les conditions du fournisseur sur la rétention, l’entraînement et la confidentialité font partie de la conception d’intégration, pas d’une note de bas de page achats.

Latence et timeouts : les appels IA ajoutent de quelques centaines de millisecondes à plusieurs dizaines de secondes à un workflow. Si le système appelant a une attente synchrone (une interface qui attend la réponse, un service en aval avec un timeout strict), l’intégration doit être asynchrone, paginée ou optimiste. Faire comme si l’IA était instantanée est la manière dont des flux utilisateurs deviennent inutilisables.

Monitoring et observabilité : l’intégration IA doit faire remonter le même type de télémétrie que le reste de la stack de production (latence, taux d’erreur, débit, par locataire ou par workflow), dans les mêmes outils d’observabilité que l’équipe d’astreinte utilise déjà. Un tableau de bord IA séparé que personne d’astreinte n’ouvre, c’est du théâtre de monitoring.

Fenêtres de changement : dans un environnement régulé ou en grande entreprise, déployer une modification d’un système connecté n’est pas une action gratuite. Les cycles de release d’intégration sont trimestriels, pas hebdomadaires, et les fonctionnalités IA s’adossent à cette cadence. Concevoir pour cela (versioning, feature flags, dark launch) évite beaucoup d’escalades plus tard.

Ces contraintes sont aussi là où la checklist de préparation IA prend corps en pratique : chaque point de la checklist a une implication de conception d’intégration, et sauter la conversation d’intégration est la manière dont la préparation devient un exercice de papier.

L’erreur de workflow la plus courante dans une intégration IA, c’est de redessiner le flux de l’utilisateur autour de l’IA plutôt que d’adapter l’IA au flux de l’utilisateur. L’intégration technique peut être correcte, mais l’utilisateur doit apprendre un nouvel outil, un nouvel écran, un nouvel endroit où regarder, en plus de faire son travail, et l’adoption cale.

Deux choix de conception tiennent cela en respect. D’abord, la sortie de l’IA apparaît au même endroit où l’utilisateur va déjà chercher ce type d’information : la page de détail du dossier, la fenêtre de rédaction de l’e-mail, la barre de recherche, la boîte de réception concernée. Pas dans un panneau « assistant IA » séparé qui demande une nouvelle habitude. Ensuite, l’utilisateur garde les verbes qu’il avait déjà. Il envoie toujours l’e-mail ; l’IA ne fait que le rédiger. Il ferme toujours le dossier ; l’IA n’a fait que suggérer la résolution. Retirer les verbes de l’utilisateur et les remplacer par « approuver l’action de l’IA » est généralement ressenti comme une régression, même quand cela fait gagner du temps.

L’IA doit changer ce qui est à l’écran, pas l’endroit où l’utilisateur doit regarder ou ce sur quoi il doit cliquer pour agir. Quand cela est juste, l’intégration disparaît, et c’est l’objectif.

La dernière contrainte est la plus sous-discutée dans les articles IA et la plus douloureuse en pratique : les systèmes existants doivent continuer à fonctionner. Le CRM doit toujours gérer un million d’enregistrements. Le workflow de dossiers doit toujours clôturer les dossiers dans les délais. Le pipeline de reporting doit toujours produire le fichier mensuel pour le régulateur.

Trois habitudes rendent la régression moins probable. La première, c’est de déployer l’IA derrière un feature flag avec un périmètre par locataire ou par utilisateur, pour que le nouveau comportement puisse être activé progressivement et désactivé proprement sans redéployer. La deuxième, c’est de faire tourner l’IA en mode shadow avant qu’elle n’ait le droit d’influencer les décisions : elle calcule sa sortie, la sortie est loguée et comparée à ce que l’humain ou le système hérité a fait, mais elle ne change pas la décision visible par l’utilisateur tant que la comparaison ne montre pas une précision acceptable. La troisième, c’est de posséder un test de régression pour le système hôte qui attrape quand l’intégration IA casse autre chose (par exemple : le workflow CRM échoue désormais pour une catégorie de dossier précise, le pipeline de reporting laisse silencieusement tomber le nouveau champ, l’assertion SSO est tronquée).

Ce ne sont pas des pratiques d’ingénierie exotiques. Ce sont les mêmes disciplines que les équipes d’intégration matures utilisent déjà. Là où les intégrations IA se mettent en difficulté, c’est quand le travail IA est traité comme une chose nouvelle et spéciale qui n’en aurait pas besoin.

L’intégration IA n’est pas un problème de modèle, c’est un problème de systèmes avec un modèle attaché. Les organisations qui obtiennent une valeur mesurable des fonctionnalités IA en production sont celles qui traitent l’intégration avec la même discipline d’ingénierie qu’elles appliqueraient à n’importe quel autre changement sur un CRM, un ERP ou un workflow régulé : conçue dès le départ pour l’identité, la résidence des données, la latence, le monitoring et le rollback, et adaptée à l’endroit où l’utilisateur travaille déjà.

Le contexte plus large, dont la manière dont la conception d’intégration se relie à la stratégie IA, à la gouvernance, à la préparation et à la sélection des cas d’usage, est rassemblé dans le cluster stratégie IA et automatisation. Et lorsque la question passe de « nous avons une fonctionnalité IA prête » à « nous devons maintenant l’intégrer à un CRM, à un SSO, à un ERP et à un workflow existant sans en casser aucun », c’est exactement ce sur quoi mon accompagnement développement d’API et intégration de systèmes est construit.