Développement IA

Définir le périmètre

Ce que « développement IA » recouvre réellement

Le terme prête à confusion parce qu’il désigne deux métiers très différents. Le premier consiste à entraîner un modèle : rassembler un corpus, dimensionner une architecture, mobiliser des moyens de calcul importants. Le second consiste à bâtir une application autour d’un modèle déjà entraîné, accessible par API. C’est ce second métier que recouvrent la plupart des projets d’entreprise, et c’est celui dont parle cette rubrique.

La conséquence est libératrice : la barrière d’entrée n’est plus la puissance de calcul, mais la clarté du besoin. Un développeur qui sait appeler une API, structurer des données et concevoir une interface possède déjà l’essentiel. Ce qui manque le plus souvent, ce sont les réflexes propres au non-déterminisme : un modèle ne renvoie pas deux fois la même chose, il ne signale pas qu’il ignore une réponse, et il ne connaît de votre entreprise que ce que vous lui transmettez dans la requête.

Faire le bon choix

Développer ou acheter

Le développement sur mesure n’est pas la réponse par défaut. Il se justifie quand le besoin touche à des données ou à des règles qui n’existent nulle part ailleurs que chez vous.

Situation	Réponse adaptée	Pourquoi
Rédiger, traduire, résumer des contenus courants	Un assistant du marché	Le besoin est générique, l’outil existe et évolue sans vous
Enchaîner des applications déjà connectables	Une plateforme d’automatisation	Les connecteurs sont maintenus par l’éditeur
Répondre à partir de documents internes	RAG sur mesure ou solution outillée	Dépend du volume, de la confidentialité et de la fraîcheur des sources
Appliquer des règles métier propres à l’entreprise	Développement sur mesure	Aucun éditeur ne connaît vos règles
Exposer un système interne à un agent	Développement sur mesure	L’interface n’existe que chez vous

Les signaux qui justifient un développement

• La connaissance nécessaire est enfermée dans vos documents, votre base ou vos exports, et n’est accessible par aucun produit existant.
• Le processus comporte des règles de gestion propres à votre activité, qu’aucun paramétrage standard ne reproduit.
• Les données traitées ne peuvent pas quitter un périmètre d’hébergement défini par contrat ou par obligation réglementaire.
• Le résultat doit s’insérer dans une interface où vos équipes travaillent déjà, et non dans un outil supplémentaire à ouvrir.
• Le volume d’usage rend l’abonnement par utilisateur plus coûteux qu’un accès direct aux API.

Les pièges classiques

Le premier est de commencer par la technologie. Un projet qui démarre par « il nous faut du RAG » avant d’avoir formulé la question à laquelle l’outil doit répondre produit une infrastructure sans utilisateur. Le second est de confondre la démonstration et le produit : un prototype qui répond correctement à dix questions choisies ne dit rien de son comportement sur mille questions réelles, souvent mal formulées, hors sujet ou piégeuses.

Le troisième est d’oublier le coût d’exploitation. Un appel de modèle se facture à l’usage : chaque requête, chaque document injecté dans le contexte, chaque relance a un prix. Un outil séduisant en démonstration peut devenir déraisonnable à l’échelle si personne n’a modélisé la consommation avant la mise en production.

Le quatrième, le plus coûteux à rattraper, est l’absence de jeu d’évaluation. Sans une liste de cas de référence avec leurs réponses attendues, aucune modification de prompt, aucun changement de modèle, aucune évolution de la base documentaire ne peut être validée autrement qu’à l’intuition.

Conduite de projet

Méthode de projet

Cadrer avant de coder

Le cadrage tient en quatre questions, à écrire noir sur blanc avant la première ligne de code. Quelle décision ou quelle tâche l’outil doit-il alléger ? Qui l’utilise, dans quel contexte, à quelle fréquence ? Quelles sources de vérité doit-il interroger ? Et à quoi reconnaîtra-t-on qu’il fonctionne, avec un critère observable et non une impression ?

Cette dernière question est celle qui détermine la suite du projet. « Les réponses sont bonnes » n’est pas un critère. « Sur nos trente questions de référence, la réponse cite le bon document et ne contient aucune information absente de ce document » en est un.

Prototyper sur le cas le plus difficile

Le réflexe naturel est de prototyper sur le cas le plus simple, parce qu’il donne un résultat rapide. C’est l’inverse qu’il faut faire. Le prototype doit attaquer le cas le plus représentatif de la difficulté réelle : la question ambiguë, le document mal structuré, la demande qui recoupe trois sources. S’il tient sur ce terrain, le reste suivra. S’il échoue, l’échec coûte quelques jours plutôt que quelques mois.

Évaluer la qualité des réponses

Un jeu d’évaluation est une liste de cas d’entrée associés à ce qu’on attend en sortie. Il se constitue à la main, avec les personnes qui feront le travail, et il grossit à chaque anomalie constatée en production. Il sert de filet : toute modification du prompt, du modèle ou du corpus se rejoue dessus avant déploiement.

Trois familles de critères sont utiles à distinguer. L’exactitude : l’information est-elle correcte au regard de la source ? L’ancrage : chaque affirmation est-elle rattachable à un passage réellement présent dans le corpus ? Le comportement en absence de réponse : le système dit-il qu’il ne sait pas, ou comble-t-il le vide ? Ce troisième critère est celui qu’on oublie le plus souvent et celui qui fait le plus de dégâts en production.

Coûts d’exploitation et maintenance

Un outil IA ne se livre pas, il s’exploite. Trois postes structurent son coût dans la durée : la consommation d’API, proportionnelle à l’usage et à la quantité de contexte envoyée à chaque requête ; l’hébergement de l’application et, le cas échéant, de la base vectorielle ; et le travail humain de mise à jour du corpus et de suivi des réponses.

S’y ajoute une contrainte propre à ce domaine : les modèles évoluent, et les fournisseurs retirent périodiquement les anciennes versions. Un projet conçu sans couche d’abstraction sur l’appel du modèle se retrouve à réécrire son cœur applicatif à chaque changement. Isoler cet appel derrière une interface interne dès le départ coûte peu et évite cette dette.

Applications concrètes

Cas d’usage

• Un assistant interne qui répond aux questions des équipes à partir de la documentation réelle de l’entreprise, en citant le document d’origine.
• Un outil de qualification qui lit les demandes entrantes, en extrait les éléments structurants et prépare le dossier avant intervention humaine.
• Un générateur de documents commerciaux ou contractuels à partir de modèles validés et de données client existantes.
• Une brique d’analyse qui résume, classe et route un flux continu de contenus vers les bons destinataires.
• Une couche de contrôle qui relit une production existante et signale les écarts par rapport à un référentiel interne.

Le point commun de ces cinq exemples : l’IA n’y prend aucune décision engageante seule. Elle prépare, propose, signale. La validation reste humaine. C’est ce qui rend ces projets déployables sans exposer l’entreprise à une erreur non détectée.

Ce qu’on nous demande

Questions fréquentes

Faut-il entraîner son propre modèle ?

Rarement. Entraîner un modèle depuis zéro suppose un corpus et des moyens de calcul hors de portée d’un usage métier. Le réglage fin d’un modèle existant est plus accessible, mais il répond à un besoin précis : imposer un format de sortie ou un style, pas apprendre des connaissances. Pour faire connaître vos données à un modèle, le RAG est la voie normale, et il présente l’avantage décisif de se mettre à jour en changeant un document, sans réapprentissage.

Où héberger une solution IA pour rester conforme au RGPD ?

La question se décompose. L’application et la base documentaire peuvent être hébergées où vous le décidez, y compris en Europe ou sur vos propres serveurs. Le modèle, lui, dépend du fournisseur : plusieurs proposent des régions d’hébergement européennes et des engagements contractuels de non-réutilisation des données envoyées par API. Ces conditions varient selon l’offre et changent régulièrement. Elles se vérifient dans le contrat en vigueur au moment du projet, pas dans un article. Une alternative existe : faire tourner un modèle ouvert sur une infrastructure que vous contrôlez, au prix d’un travail d’exploitation supplémentaire.

Comment éviter les réponses inventées ?

On ne les élimine pas, on les rend rares et détectables. Trois leviers agissent ensemble : ancrer la réponse dans des passages fournis explicitement au modèle plutôt que de compter sur sa mémoire ; lui demander de citer la source de chaque affirmation, ce qui rend la vérification possible ; et l’autoriser explicitement à répondre qu’il ne sait pas, en le testant sur des questions volontairement hors corpus. Un système qui n’a jamais répondu « cette information ne figure pas dans les documents » n’a pas été évalué sur ce point.

Peut-on changer de fournisseur de modèle en cours de route ?

Oui, à condition de l’avoir prévu. Techniquement, les formats d’appel se ressemblent souvent assez pour qu’une couche d’abstraction interne limite le travail de remplacement. La vraie difficulté est ailleurs : les prompts optimisés pour un modèle ne produisent pas le même résultat sur un autre. C’est le jeu d’évaluation qui rend le changement gérable. Il indique en une exécution ce qui se dégrade et ce qui s’améliore.

Combien de temps pour un premier outil utilisable ?

Cela dépend presque entièrement de l’état de vos données, rarement du code. Quand le corpus est propre, à jour et déjà accessible par un moyen technique, un prototype fonctionnel arrive vite. Quand la connaissance est dispersée dans des PDF scannés, des fichiers partagés et la tête de trois personnes, l’essentiel du projet consiste à la rassembler, et cette phase-là ne se raccourcit pas avec de la technologie.