Intelligence artificielle : quatre familles, quatre usages

« Faire de l’IA » ne veut rien dire. Derrière le mot se cachent des techniques qui n’ont ni les mêmes forces, ni les mêmes coûts, ni les mêmes conditions de réussite, et le choix de la mauvaise famille explique une bonne part des projets qui n’aboutissent pas.

Un modèle de langage à qui l’on demande de prévoir un chiffre d’affaires produira une réponse plausible et fausse. Un modèle statistique à qui l’on demande de résumer un contrat n’ira nulle part. La première décision d’un projet n’est donc pas quel fournisseur choisir, c’est de quelle famille relève le problème.

Cette page décrit les quatre que nous rencontrons en mission, sans plaidoyer pour aucune.

Un modèle de langage prédit la suite d’un texte. Tout ce qu’il sait faire découle de là, et ses limites aussi.

Ce qu’il fait remarquablement bien : transformer du texte non structuré en données exploitables. Lire mille descriptions de produits et en extraire une catégorie, une matière et une dimension. Classer des courriels entrants. Résumer des comptes rendus. Rédiger un premier jet. Ce sont des tâches que personne n’automatisait il y a trois ans parce qu’elles demandaient de comprendre le sens, et elles représentent aujourd’hui l’essentiel de la valeur réellement captée en entreprise.

Ce qu’il fait mal, et qu’il faut savoir avant de commencer : il ne calcule pas. Il produit une réponse vraisemblable, ce qui n’est pas la même chose qu’une réponse juste. Sur un chiffre, une somme, une prévision, la vraisemblance ne suffit pas. Il ne connaît pas non plus votre entreprise, sauf à lui fournir vos données, ce qui est précisément l’objet de la famille suivante.

La question du fournisseur vient loin derrière celle de l’usage. Nous travaillons avec les modèles d’OpenAI, ceux d’Anthropic et des modèles ouverts exécutés sur votre propre matériel quand la confidentialité l’impose. Le critère qui tranche est rarement la performance brute : c’est le cadre contractuel, le lieu d’exécution et le coût au volume.

Un modèle de langage ne connaît pas vos procédures, vos contrats ni vos comptes rendus. Deux voies existent pour l’en informer : le réentraîner sur vos données, coûteux et vite périmé, ou lui fournir les bons extraits au moment de la question. La seconde s’appelle la génération augmentée par la recherche, en abrégé RAG, et c’est presque toujours la bonne.

Le principe tient en trois temps. Vos documents sont découpés en passages et indexés dans une base capable de rechercher par le sens plutôt que par les mots exacts. À la question posée, le système retrouve les passages pertinents. Ces passages sont donnés au modèle, qui rédige sa réponse à partir d’eux et cite ses sources.

Cette citation est l’intérêt principal, bien plus que la fluidité de la réponse. Un assistant qui indique de quel document et de quel paragraphe vient son affirmation est vérifiable ; un assistant qui affirme sans référence ne vaut pas mieux qu’une rumeur. Sur des sujets où l’erreur coûte cher, contrats, procédures, réglementation, c’est ce qui rend l’outil utilisable.

Là où les projets échouent, ce n’est presque jamais sur le modèle. C’est sur le découpage des documents, sur la qualité de la recherche et sur les droits d’accès, quand tout le monde se retrouve à interroger des documents que tout le monde n’a pas le droit de lire. Ces trois points se règlent en amont, avant de choisir quoi que ce soit.

Le protocole MCP est la suite logique de cette famille : au lieu de fournir au modèle des extraits de documents, on lui donne accès à vos outils métier. C’est ce que nous faisons sur la comptabilité et la paie.

C’est la famille la plus ancienne, la moins spectaculaire, et celle que la mode fait injustement oublier. Elle répond à des questions que les modèles de langage ne savent pas traiter : quels clients risquent de partir ce trimestre, quelle sera la demande le mois prochain, cette transaction ressemble-t-elle à une fraude, ce dossier mérite-t-il un contrôle.

Trois avantages décident souvent en sa faveur. Elle travaille sur vos données tabulaires, celles que vous avez déjà. Elle se mesure : on sait dire si le modèle se trompe, de combien, et sur quels cas. Et elle s’explique, ce qui compte dès qu’une décision doit être justifiée à un client, à un comité ou à un contrôleur.

Son coût réel n’est pas dans l’algorithme, qui est aujourd’hui une affaire de quelques lignes. Il est dans l’historique : sans plusieurs années de données propres et cohérentes, il n’y a rien à apprendre. C’est la raison pour laquelle nous commençons souvent par le socle de données avant de parler de modèle, et pour laquelle un projet de prévision se transforme régulièrement en projet de mise en ordre des données.

Nous avons industrialisé des modèles sur Amazon SageMaker, qui prend en charge l’entraînement, le déploiement et le suivi une fois que l’on quitte le carnet d’exploration. Sur des volumes plus modestes, un entraînement en Python orchestré par Airflow suffit et coûte bien moins cher.

La vision par ordinateur recouvre deux réalités très différentes, qu’il vaut mieux ne pas confondre.

La première est industrielle : détecter un défaut sur une chaîne, compter des objets, lire une plaque ou un code. Elle demande des caméras, des conditions d’éclairage maîtrisées et un travail d’annotation, et elle relève d’un projet d’automatisation davantage que d’un projet data.

La seconde est celle que rencontrent la plupart des entreprises : lire des documents. Factures, bons de livraison, contrats, formulaires, relevés. C’est là que le domaine a le plus bougé, et là que nous intervenons.

Deux approches coexistent, et le bon choix dépend de vos documents. Les bibliothèques spécialisées comme docTR, à code ouvert, s’exécutent chez vous, ne dépendent d’aucun fournisseur et se maîtrisent au centime près : c’est la voie à privilégier quand les documents sont réguliers et que les données ne doivent pas sortir. Les modèles de compréhension de documents, comme celui de Mistral, lisent en une passe des mises en page complexes, des tableaux et des écritures difficiles, sans être entraînés pour chaque format : ils coûtent à l’appel mais suppriment l’essentiel du travail de paramétrage.

Le point que nous répétons en cadrage : une reconnaissance de caractères ne vaut que par ce qui vient après. Extraire un montant est facile, savoir que ce montant est le total et non un sous-total demande de comprendre le document, et rapprocher ce total d’une écriture comptable demande de connaître le métier. La valeur n’est pas dans la lecture, elle est dans le contrôle qui suit.

La question qui tranche le plus vite est celle de la nature de la réponse attendue.

Si la réponse est un texte à produire ou à comprendre, vous êtes dans la première famille. Si elle doit s’appuyer sur vos documents et être vérifiable, dans la deuxième. Si c’est un nombre, une probabilité ou une classe qui doit être juste et mesurable, dans la troisième. Si l’entrée est une image ou un document scanné, dans la quatrième, avec la troisième ou la première juste derrière pour en faire quelque chose.

Une deuxième question évite beaucoup de dépenses : que fait-on de la réponse ? Si personne n’a prévu ce qui se passe une fois la prévision produite ou le document lu, le projet s’arrêtera à la démonstration, quelle que soit la famille retenue. C’est de très loin la cause d’échec la plus fréquente, et elle n’a rien de technique.

Enfin, aucune de ces familles ne rattrape des données fausses. Un modèle entraîné sur un historique incohérent apprend l’incohérence, un assistant branché sur des documents périmés cite des documents périmés. Quand nous constatons ce cas, nous le disons avant de chiffrer quoi que ce soit.

Nous ne vendons pas une offre d’intelligence artificielle. Nous intervenons sur les couches où le sujet rejoint la donnée : préparer le socle sans lequel rien ne fonctionne, brancher un modèle sur vos systèmes de façon gouvernée, industrialiser ce qui est resté à l’état de carnet d’exploration, et dire quand la réponse n’est pas dans l’IA.

Cette dernière partie n’est pas une formule. Une bonne moitié des besoins qui nous arrivent formulés comme des projets d’IA se traitent mieux avec une requête, un tableau de bord ou une automatisation sans modèle. Le dire coûte une mission et en évite une mauvaise.

Si vous ne savez pas encore de quelle famille relève votre besoin, l’audit IA répond à cette question en cinq jours, et le diagnostic de préparation donne une première orientation en quelques minutes.

Quelle différence entre l’IA générative et le machine learning ?

Un modèle de langage prédit la suite d’un texte : il excelle à transformer du texte non structuré en données exploitables, à classer, résumer ou rédiger, mais il ne calcule pas et produit une réponse vraisemblable plutôt que juste. L’apprentissage automatique travaille sur des données tabulaires et répond à des questions chiffrées, prévision de demande, risque de départ, détection de fraude, avec deux avantages décisifs : on peut mesurer son erreur et on peut expliquer sa décision.

Qu’est-ce que le RAG et quand l’utiliser ?

Le RAG, ou génération augmentée par la recherche, consiste à retrouver les passages pertinents de vos documents au moment de la question, puis à les fournir au modèle qui rédige sa réponse à partir d’eux et cite ses sources. C’est presque toujours préférable au réentraînement, coûteux et vite périmé. L’intérêt principal est la citation des sources, qui rend la réponse vérifiable. Les échecs viennent rarement du modèle : ils viennent du découpage des documents, de la qualité de la recherche et des droits d’accès.

Faut-il un modèle de langage ou un OCR pour lire des factures ?

Cela dépend des documents. Les bibliothèques spécialisées à code ouvert comme docTR s’exécutent chez vous, ne dépendent d’aucun fournisseur et se maîtrisent au centime près : c’est la voie à privilégier quand les documents sont réguliers et que les données ne doivent pas sortir. Les modèles de compréhension de documents, comme celui de Mistral, lisent en une passe des mises en page complexes et des tableaux sans paramétrage par format, mais coûtent à l’appel. Dans les deux cas, la valeur n’est pas dans la lecture mais dans le contrôle qui suit.

Pourquoi les projets d’IA n’arrivent-ils pas en production ?

Deux causes dominent, et aucune n’est technique. La première est le choix de la mauvaise famille de techniques : demander une prévision chiffrée à un modèle de langage produit une réponse plausible et fausse. La seconde est l’absence de décision en aval : si personne n’a prévu ce qui se passe une fois la prévision produite ou le document lu, le projet s’arrête à la démonstration. S’y ajoute le fait qu’aucune technique ne rattrape des données fausses.

Quelles technologies d’IA Data SL Consulting met-elle en œuvre ?

Le cabinet ne vend pas une offre d’intelligence artificielle : il intervient sur les couches où le sujet rejoint la donnée. Cela couvre les modèles d’OpenAI et d’Anthropic ainsi que des modèles ouverts exécutés sur le matériel du client quand la confidentialité l’impose, les architectures RAG et le protocole MCP pour brancher un assistant sur les outils métier, l’industrialisation de modèles sur Amazon SageMaker ou en Python orchestré par Airflow, et la lecture de documents avec docTR ou le modèle de compréhension de documents de Mistral.

• MCP, la norme qui donne à un assistant l’accès à vos outils métier.
• Agent IA connecté à vos données, la mise en œuvre côté entreprise.
• Python, où il est irremplaçable dans une chaîne de données et où il coûte cher.
• Panorama des technologies sur lesquelles nous intervenons.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : docTR, OCR Mistral, Amazon SageMaker.

Pour un usage plus immédiat et sans projet, voyez ce que l’IA change concrètement dans Excel.