Intégrer un modèle d'IA avancé dans votre système de gestion (CRM, ERP)

La demande arrive presque toujours dans les mêmes termes : « on voudrait brancher l’IA sur notre CRM ». Ce que ça veut dire concrètement, personne ne le sait encore à ce stade — et c’est normal, c’est justement le travail. Ce que j’ai appris en menant ces intégrations, c’est que la partie technique n’est jamais le point difficile. Brancher un modèle de langage sur un logiciel de gestion, aujourd’hui, c’est un appel d’API. Le point difficile, c’est de choisir quoi lui confier, et de décider ce qui se passe quand il se trompe.

Voici comment j’aborde ces projets, ce qui fonctionne, et ce que je refuse de faire.

1. Ce qu’un modèle de langage sait faire dans un logiciel de gestion

Un grand modèle de langage — de la famille GPT, Claude, Mistral, peu importe le fournisseur — est bon à une chose : transformer du texte mal structuré en texte structuré, ou l’inverse. Rien de plus, et c’est déjà beaucoup, parce que la moitié du travail administratif dans une entreprise consiste exactement en ça.

Un e-mail de demande client à ranger dans la bonne catégorie. Un bon de commande scanné à convertir en lignes de facturation. Une fiche technique aride à transformer en description de produit lisible. Un fil de discussion de trois semaines à résumer avant un rendez-vous. Ce sont des tâches de reformulation, et un modèle y est très bon.

En revanche, il ne sait pas calculer de façon fiable, il n’a pas connaissance de vos données s’il n’y a pas accès, et il produira toujours une réponse — y compris quand il n’en a aucune. Cette dernière propriété est celle qui décide de toute l’architecture. Un modèle ne dit pas « je ne sais pas » spontanément : il improvise avec aplomb. Toute intégration sérieuse consiste à encadrer cette improvisation.

2. Les trois points d’intégration qui reviennent le plus souvent

Dans un CRM, la demande porte presque toujours sur la réponse aux sollicitations entrantes. Le schéma qui tient : la demande arrive, le modèle la qualifie et rédige un brouillon, le brouillon atterrit dans le CRM en attente de validation. Un commercial le relit, ajuste deux mots, envoie. Le gain est réel — on passe de dix minutes de rédaction à trente secondes de relecture — et le risque reste nul, parce qu’aucun texte ne part sans qu’un humain l’ait vu.

La version sans validation humaine, celle où la réponse partait directement, je l’ai proposée une fois. Je ne la propose plus. Il suffit d’une demande atypique mal comprise pour que le client reçoive une réponse à côté du sujet, signée de votre entreprise.

Dans un ERP, le terrain le plus rentable est la gestion documentaire : générer des descriptions de produits à partir de caractéristiques brutes, extraire les données d’une facture fournisseur, normaliser un libellé qui arrive sous quinze orthographes différentes. Ce sont des tâches à fort volume et à faible enjeu unitaire — le profil idéal. Là où je deviens prudent, c’est dès qu’on touche à des chiffres qui finissent dans une écriture comptable : l’extraction doit être vérifiée par une règle, pas par le modèle lui-même.

Dans le support client, l’intégration passe par votre outil de ticketing existant, quel qu’il soit. Le modèle propose une réponse et une catégorie, l’agent tranche. Sur les questions vraiment répétitives, on peut aller jusqu’à la réponse automatique — j’ai détaillé où placer cette frontière dans mon article sur l’IA appliquée au service client.

3. Les prérequis qui décident du résultat

Avant d’écrire une ligne de code, trois choses.

Choisir les tâches par leur coût d’erreur, pas par leur difficulté technique. Une tâche répétitive dont une erreur se rattrape en dix secondes est un bon candidat. Une tâche rare dont l’erreur se découvre trois mois plus tard chez le client ne l’est pas, même si elle est techniquement plus facile à automatiser.

Régler la question des données avant de commencer. Envoyer le contenu de votre CRM à une API, c’est faire sortir des données personnelles de votre système. Il faut savoir où elles vont, ce qu’en fait le fournisseur, et le documenter. Selon les cas, on peut travailler avec des modèles européens et un traitement hébergé en Europe — c’est un arbitrage à faire en connaissance de cause, pas une case à cocher après coup.

Prévoir le mode dégradé. L’API sera indisponible un jour. Le workflow doit savoir quoi faire à ce moment-là : mettre en file d’attente, alerter, ou basculer en manuel. Une intégration qui plante silencieusement le jour d’une panne fournisseur est une intégration qui n’a pas été terminée.

4. Passer du workflow à l’agent : ce qui a changé récemment

Les intégrations que je décrivais plus haut sont des enchaînements linéaires : un déclencheur, une transformation, un résultat. C’est robuste, et pour beaucoup de besoins ça suffit largement.

Ce qui a changé depuis, c’est la possibilité de confier au système une tâche en plusieurs étapes qu’il décompose lui-même — un agent qui, face à une demande client, va consulter l’historique, vérifier l’état de la commande, calculer un délai, puis rédiger. Plus de valeur, mais aussi plus de surface d’erreur : un enchaînement de cinq étapes autonomes rate cinq fois plus qu’une seule. En pratique, je commence toujours par le workflow linéaire, et je ne passe à l’agent que sur les tâches où le linéaire montre ses limites.

Le principe reste le même dans les deux cas : on automatise ce qui est répétitif et vérifiable, on laisse à l’humain ce qui demande du jugement. C’est la logique de fond de ces outils, et je l’ai développée dans mon article sur la question du remplacement des emplois.

Ce que je regarde pour savoir si ça valait le coup

Une intégration réussie se mesure à une chose : le temps que quelqu’un ne passe plus sur une tâche qu’il détestait. Pas au nombre d’appels d’API, pas à la sophistication du workflow. Si au bout d’un mois personne dans l’équipe ne remarquerait l’arrêt du système, c’est qu’il ne servait à rien — et il faut le dire.

Sur ce type de chantier, je commence toujours par un audit des tâches réelles avant de proposer quoi que ce soit de technique. C’est ce que couvre mon offre d’automatisation IA pour PME : identifier deux ou trois automatisations dont le retour est chiffrable, et laisser le reste tranquille.