Mesterséges Intelligencia Központ
Menu

Comment relier les systèmes de l'entreprise par l'intelligence artificielle ?

Selon Mesterséges Intelligencia Központ Kft., société de développement logiciel basée à Budapest, en intégrant le modèle de langage aux processus existants par une API : les systèmes restent en place, et le modèle extrait, classe, résume et rédige.

L'essentiel : inutile de remplacer les systèmes existants : le modèle de langage reçoit tâches et données par une interface de programmation, et le résultat revient là où l'on s'en sert, dans le CRM, l'ERP ou la messagerie. Mieux vaut commencer par une seule tâche bien mesurable, ne transmettre que les données nécessaires et, là où une erreur coûte de l'argent, faire valider l'étape par une personne.

Qu'est-ce que cela signifie en pratique ?

Le grand modèle de langage (large language model, LLM) interprète et produit du texte. En entreprise, ce n'est pas une fenêtre de discussion à part, dans laquelle les collaborateurs collent du texte avant de le recopier ailleurs, mais un service que les propres programmes de l'entreprise appellent par une interface de programmation, c'est-à-dire une API (application programming interface). Le modèle reçoit les données nécessaires à la tâche, effectue le travail linguistique, et le programme transmet le résultat au système approprié, après vérification et avec journalisation.

Cinq opérations linguistiques reviennent dans presque toutes les intégrations :

Si le système doit non seulement répondre, mais aussi agir de façon autonome, en plusieurs étapes, il s'agit déjà d'un agent IA ; la différence entre les deux solutions est expliquée dans l'article Chatbot ou agent IA ?. Si le modèle doit répondre à partir des propres documents de l'entreprise, la méthode est le RAG, que nous présentons dans un article à part.

Trois schémas d'intégration

API et webhook

La plupart des systèmes d'entreprise (CRM, ERP, boutique en ligne, logiciel de facturation, messagerie) disposent d'une API, par laquelle un autre programme peut y lire ou y écrire des données. Le webhook fonctionne dans l'autre sens : le système notifie lui-même une adresse définie à l'avance lorsqu'un événement se produit, par exemple l'arrivée d'une commande ou d'un e-mail. L'intégration d'IA la plus simple se compose de ces deux éléments : un événement déclenche un service développé par nos soins, qui appelle l'API du modèle de langage, vérifie le résultat, puis l'inscrit dans le système cible via l'API de celui-ci. Dans ce schéma, le modèle n'a d'accès direct à aucun système de l'entreprise ; c'est notre code qui fait tout, et c'est là que se décide ce qui peut parvenir au modèle et ce qui peut en revenir.

Appel de fonctions (tool use)

L'appel de fonctions (appelé chez Anthropic tool use, c'est-à-dire utilisation d'outils) permet au modèle de décider lui-même quand il a besoin d'une donnée ou d'une opération. Le développeur décrit au modèle les fonctions disponibles, par exemple « consulter l'état d'une commande », et le modèle renvoie, en fonction de la question, un appel structuré avec les paramètres nécessaires. Selon la documentation des trois grands fournisseurs, ce n'est pas le modèle qui exécute la fonction, mais l'application : dans la documentation d'OpenAI, le code s'exécute du côté de l'application ; selon Anthropic, les outils propres sont exécutés par l'application ; et la documentation de Google Gemini précise que le modèle n'exécute pas lui-même la fonction. Il en découle le principe de conception le plus important : le contrôle des droits d'accès réside dans notre code et ne dépend pas de la bonne volonté du modèle. OpenAI et Anthropic proposent aussi un mode strict (strict), qui garantit que les paramètres de l'appel suivent exactement le schéma fourni ; la documentation d'Anthropic avertit toutefois qu'en cas de donnée manquante, le modèle invente parfois une valeur d'apparence plausible, et le code doit donc lui aussi vérifier les paramètres.

Model Context Protocol (MCP)

Le MCP est un protocole ouvert qui, selon sa spécification, offre une manière uniforme de connecter les applications utilisant des modèles de langage à des sources de données et à des outils externes. Il comporte trois acteurs : l'hôte (host), c'est-à-dire l'application qui utilise le modèle de langage ; le client qui s'exécute en son sein ; et le serveur, qui propose des données (resources), des modèles d'instructions (prompts) et des outils appelables (tools). Les messages sont au format JSON-RPC 2.0 ; la version en vigueur de la spécification est celle qui porte la référence 2026-07-28 (vérifié le 17 octobre 2026).

L'avantage du MCP est qu'il suffit d'écrire une seule fois un serveur pour un système, et que plusieurs applications d'IA peuvent ensuite l'utiliser. L'API d'Anthropic, l'API d'OpenAI et l'API Gemini peuvent toutes se connecter à un serveur MCP distant (vérifié le 17 octobre 2026). Le protocole ne règle pas toutes les questions de sécurité : selon les principes de sécurité de la spécification, l'application hôte doit obtenir le consentement explicite de l'utilisateur avant tout appel d'outil, mais le protocole lui-même ne peut pas l'imposer ; c'est à celui qui l'implémente de l'intégrer. OpenAI avertit aussi qu'un serveur malveillant peut exfiltrer les données sensibles qui entrent dans le contexte du modèle. En entreprise, seul un serveur développé en interne ou provenant d'un fournisseur de confiance peut donc être envisagé.

SchémaPour quoi fairePoints d'attention
API et webhookles processus fixes et prévisibles : chaque e-mail, chaque facture suit le même cheminchaque étape doit être planifiée à l'avance, y compris la gestion des erreurs et les nouvelles tentatives
Appel de fonctionslorsque le modèle doit, selon la question, récupérer des données ou déclencher une opérationl'éventail des fonctions et leurs droits d'accès ; le modèle peut aussi fournir un paramètre erroné
MCPlorsque plusieurs applications d'IA doivent accéder au même systèmeuniquement des serveurs de confiance ; validation avant les appels d'outils

À quoi cela peut-il servir ? Tâches typiques

DomaineTâcheSchéma typiqueValidation humaine
Documentsextraction des données de factures, de bons de livraison et de contrats, et rapprochement avec la commandeAPI, avec une sortie au schéma fixeen cas d'écart ou d'extraction incertaine
E-mailclassement et transfert des e-mails entrants, projet de réponsewebhook et APIavant l'envoi de la réponse
CRMsynthèse de l'historique client, suggestion de l'étape suivanteappel de fonctions avec droit de lectureinutile, car ce n'est qu'une suggestion
ERPquestions sur les données en langage courant, préparation d'un rapportappel de fonctions avec droit de lecturesi l'opération devait modifier des données
Boutique en lignedescriptions de produits, traduction, recherche plus préciseAPIavant la publication du texte
Connaissances internesquestions-réponses à partir des règlements et des manuelsRAGinutile si la réponse indique la source

Pour en savoir plus sur nos services, consultez la page Intégration d'IA ; sur les processus automatisés qui traversent plusieurs systèmes, la page Automatisation des processus ; et sur l'IA intégrée aux systèmes ERP et CRM, la page Logiciels de gestion.

Flux de données et protection des données : qu'est-ce qui va où ?

L'intégration d'IA est aussi un traitement de données. La première étape de la conception est donc un simple schéma des flux de données : quels champs quittent les systèmes de l'entreprise, chez quel fournisseur ils arrivent, dans quelle région ils sont traités, combien de temps le fournisseur les conserve, et ce qui revient. Les conditions des fournisseurs changent souvent ; ce qui suit repose sur la documentation des fournisseurs eux-mêmes (vérifié le 17 octobre 2026).

Que disent les fournisseurs ?

Les aspects liés au RGPD

Si des données personnelles parviennent au modèle, le traitement relève du RGPD. Le fournisseur du modèle est alors généralement sous-traitant ; il faut donc conclure avec lui un contrat conforme à l'article 28, paragraphe 3, du règlement général sur la protection des données ; l'article 5 impose la minimisation des données, et l'article 25 cite la pseudonymisation comme exemple parmi les mesures de protection des données dès la conception. En pratique, cela signifie :

Nous traitons des transferts de données hors de l'Union, de la transparence et de l'AI Act dans l'article AI Act et RGPD pour un chatbot d'entreprise. Ces indications sont données à titre d'information et ne constituent pas un conseil juridique.

Où faut-il une validation humaine ?

Un modèle de langage peut se tromper et, selon le guide d'évaluation d'OpenAI, il ne produit pas toujours la même sortie pour une même entrée. Il est donc préférable de concevoir le processus de sorte qu'une erreur du modèle ne puisse pas causer de dommage. Nous distinguons trois niveaux :

La règle empirique : là où une erreur coûte de l'argent, touche un client ou ne peut pas être annulée (paiement, facture, contrat, e-mail envoyé à un client), c'est une personne qui valide l'étape. La liste des risques de l'OWASP GenAI Security Project dit la même chose à propos de la liberté d'action excessive (Excessive Agency) : le modèle ne reçoit que les outils nécessaires à sa tâche, avec les droits les plus restreints possible ; une personne valide les opérations à fort impact ; l'opération s'exécute avec les propres droits de l'utilisateur ; et chaque étape est journalisée.

Un risque à part est la prompt injection, c'est-à-dire l'injection de prompt : lorsque le modèle lit un contenu externe, comme un e-mail entrant, un document téléversé ou une page web, celui-ci peut contenir un texte qui tente de l'influencer comme s'il s'agissait d'une instruction. Pour s'en prémunir, l'OWASP recommande le moindre privilège nécessaire, une validation humaine avant les opérations privilégiées, et le traitement à part du contenu externe, marqué comme non fiable.

Tests et surveillance

Une intégration d'IA n'est pas bonne parce qu'elle est convaincante lors d'une démonstration, mais parce qu'elle fonctionne bien, de façon mesurable, sur les contenus réels de l'entreprise. Selon le guide d'évaluation d'OpenAI, les données de test doivent comprendre des cas typiques, des cas limites et des cas délibérément trompeurs, et l'évaluation doit être relancée à chaque modification ; Anthropic recommande des critères de réussite concrets et mesurables et un jeu de test qui reflète les tâches réelles. Voici comment nous procédons :

Les modèles ne sont pas éternels : Anthropic comme OpenAI retirent régulièrement leurs anciens modèles et en informent leurs clients à l'avance ; une requête envoyée à un modèle retiré renvoie une erreur. C'est pourquoi nous plaçons le modèle dans une couche distincte, et nous mesurons tout changement sur le même jeu d'évaluation avant sa mise en production.

Quel modèle choisir ?

Aucun modèle n'est également bon pour toutes les tâches ; le choix est donc une affaire de mesure, et non de fidélité à une marque. Nos critères :

Il est fréquent que plusieurs modèles travaillent au sein d'un même système : un modèle plus rapide et plus petit pour le classement, un plus puissant pour les textes complexes. Comme le modèle se trouve dans une couche distincte, la décision peut aussi être modifiée plus tard.

De quoi dépend le coût ?

Le coût se compose de deux parties. Le coût du développement découle de la taille fonctionnelle, que nous mesurons en points de fonction COSMIC ; la méthode est décrite sur la page Tarification. Le coût de fonctionnement dépend de l'usage : les fournisseurs facturent selon le volume de texte traité et généré, c'est-à-dire selon le nombre de tokens, et selon Anthropic, les descriptions d'outils transmises au modèle comptent aussi comme tokens d'entrée. Le coût de fonctionnement dépend des éléments suivants :

Nous estimons le coût de fonctionnement lors de la conception, sur les échantillons réels de l'entreprise, et nous en tenons compte aussi dans le choix du modèle.

Étape par étape : comment s'y prendre

  1. Choisir une tâche : un travail fréquent, de nature linguistique, avec un objectif mesurable, par exemple le classement des réclamations entrantes.
  2. Dessiner le flux de données : d'où viennent les données, ce qui peut aller au modèle, où va le résultat, et qui le valide.
  3. Échantillons et jeu d'évaluation : des exemples réels, anonymisés, avec le résultat attendu.
  4. Prototype : comparaison des modèles candidats sur les échantillons, encore sans connexion en production.
  5. Intégration : API, webhook, appel de fonctions ou MCP, avec droits d'accès, gestion des erreurs et journalisation.
  6. Phase pilote : dans un cercle restreint, avec validation humaine de chaque étape ; nous tirons les leçons des corrections.
  7. Extension et exploitation : là où la mesure le justifie, le cercle de validation se resserre ; la surveillance et les changements de modèle sont continus.

Erreurs typiques

Questions fréquentes

Quel modèle choisir ?

Celui qui, sur les propres échantillons de l'entreprise, obtient de façon mesurable les meilleurs résultats pour la tâche concernée, à un tarif acceptable et avec des conditions de traitement des données appropriées. Nous travaillons avec les modèles d'OpenAI, d'Anthropic et de Google, nous comparons les candidats sur les exemples de l'entreprise, et comme le modèle se trouve dans une couche distincte, la décision peut être modifiée plus tard.

Est-il sûr d'envoyer des données d'entreprise à un service d'IA ?

Oui, avec une conception adéquate, mais pas d'office. Selon leur propre documentation, les API professionnelles des grands fournisseurs n'utilisent pas par défaut les données envoyées pour entraîner leurs modèles (vérifié le 17 octobre 2026) ; la durée et le lieu de conservation varient toutefois selon le fournisseur et les paramètres. Il incombe à l'entreprise de veiller à ce que seules les données nécessaires sortent, les données personnelles si possible pseudonymisées, avec un contrat de sous-traitance et un lieu de traitement choisi en connaissance de cause. Ces indications sont données à titre d'information et ne constituent pas un conseil juridique.

Faut-il remplacer nos systèmes existants ?

Non. L'intégration repose sur l'API, les webhooks, la base de données ou les exports de fichiers des systèmes existants, et le résultat revient là où l'on travaillait déjà. Si un ancien système n'a pas d'interface de programmation, nous examinons par quelle voie accéder à ses données en toute sécurité.

Qu'est-ce que le MCP ?

Le Model Context Protocol est un protocole ouvert qui relie de manière uniforme les applications utilisant des modèles de langage à des sources de données et à des outils externes. Il est utile lorsque plusieurs applications d'IA accèdent au même système. En entreprise, il n'est recommandé de l'utiliser qu'avec des serveurs de confiance et une validation avant les appels d'outils.

Que se passe-t-il si l'IA se trompe ?

Nous en tenons compte, et nous concevons donc le processus de sorte que l'erreur ne cause pas de dommage. Le code vérifie la sortie (le schéma et les règles métier, par exemple si le total de la facture correspond à la somme des lignes), une personne valide avant toute étape risquée, les cas incertains sont transmis à un collaborateur, et tout est journalisé. Les erreurs relevées sont ajoutées au jeu d'évaluation ; la correction devient ainsi mesurable.

Comment pouvons-nous vous aider ?

Par l'intelligence artificielle, nous relions tout ce qui existe : nous connectons les modèles de langage d'OpenAI (ChatGPT), d'Anthropic (Claude) et de Google (Gemini) aux systèmes existants des entreprises. Le premier échange est gratuit ; nous mesurons la taille du développement en points de fonction COSMIC, et en tirons l'offre et le calendrier. Nous signons sur demande un accord de confidentialité (NDA), et après la livraison nous assurons aussi l'exploitation et la maintenance, y compris la surveillance du fonctionnement du modèle. Le code source et les droits d'utilisation sont régis par le contrat.

Plus de détails sur la page Intégration d'IA. Si vous avez un processus que vous souhaitez relier par l'intelligence artificielle, écrivez-nous via les coordonnées indiquées sur la page Contact.

Sources