Choisir et gouverner ses modèles d’IA : une méthode en cinq étapes
Comment choisir les modèles d’IA adaptés aux usages de l’entreprise, puis garder la maîtrise de leurs évolutions ? Pour les CTO et les DSI, la réponse passe par une méthode qui relie besoins métier, contraintes d’exploitation et résultats mesurés.
par
David Guede, Partner Data et IA - Agentic expert chez Converteo
Publié le: 14 oct. 2026
Au démarrage d’un projet d’IA, le choix du modèle est une interrogation centrale. Les options oscillent généralement entre les solutions déjà disponibles chez un fournisseur cloud, la comparaison de plusieurs éditeurs et le recours à un modèle open weight. Derrière ces alternatives, les exigences restent concrètes. Il faut obtenir des résultats fiables, maîtriser les coûts et protéger les données.
Pour départager ces possibilités, le premier repère consiste à définir ce que le système devra réellement accomplir. Rédiger une réponse, analyser un dossier ou déclencher une action ne s’envisage pas de la même manière. Au sein d’un même projet, les opérations peuvent ainsi présenter des exigences différentes, notamment quant au délai et aux conséquences d’une erreur.
Le choix du modèle s’inscrit alors dans une démarche plus large. Il faut préciser les critères de réussite, comparer les solutions autorisées sur des cas représentatifs, puis vérifier qu’elles tiennent leurs engagements en production. Il ne s’agit plus seulement de sélectionner une technologie, mais de justifier le choix de celle-ci, d’identifier ses zones d’usage et de fixer les conditions de son remplacement.
Voici une méthode en cinq étapes pour organiser cet arbitrage, du cadrage de l’usage à la gouvernance des changements.
1. Qualifier l’opération et fixer les critères d’acceptation
L’expression « traiter une facture » s’avère par exemple trop large. En extraire les montants, expliquer un écart, ou déclencher un remboursement, ne présente pas les mêmes exigences.
« Réservez un jeu distinct pour la validation. Ne l’utilisez pas pour ajuster les prompts ou entraîner les modèles. »
David Guede, Partner Data et IAConverteo
Il convient de qualifier chaque opération selon cinq dimensions : données manipulées, difficultés, conséquences d’une erreur, volume et délai de réponse, capacité d’exploitation.
Une fiche d’acceptation doit être formalisée : entrées autorisées, résultat vérifiable, erreurs bloquantes, seuils de qualité et de latence, budget, conditions de reprise humaine. L’autonomie accordée doit y être précisée : proposer, faire valider ou agir. Ces critères nécessitent une approbation par le métier, la sécurité et l’exploitation avant tout essai.
Un jeu de cas représentatifs doit être constitué, complété de demandes ambiguës, de cas rares à fort impact et de tentatives de contournement. Il convient de réserver un jeu distinct pour la validation finale, sans l’utiliser pour ajuster les prompts ou entraîner les modèles.
2. Délimiter les configurations admissibles
API d’éditeur, catalogue d’un hyperscaler, modèle à poids ouverts opéré par un tiers ou auto-hébergement : chaque combinaison, de modèle, de service et d’hébergement, doit être qualifiée. Il importe aussi de vérifier le parcours des données et des journaux, la gestion des accès, la durée de conservation et les éventuelles réutilisations.
La validation des exigences juridiques et de sécurité, ainsi que du périmètre des qualifications requises, est un prérequis. Les notions de poids ouverts, d’hébergement européen et de contrôle de l’opérateur ne doivent pas être confondues.
La démarche gagne à débuter par les fournisseurs déjà contractualisés et validés, en vérifiant les conditions propres à chaque modèle. La sortie de ce périmètre doit répondre à un besoin non couvert ou à un gain mesuré qui justifient le coût contractuel, de sécurité et d’intégration.
Pour l’auto-hébergement, le chiffrage doit couvrir le service complet : infrastructure, capacité en pointe, disponibilité, supervision, mises à jour et interventions. Les compétences requises et les possibilités de mutualisation doivent y être intégrées.
L’élimination initiale des configurations incompatibles avec les exigences permet ensuite de comparer sereinement celles qui restent.
3. Choisir par étape, valider de bout en bout
Choisir par étape ne signifie ni multiplier les modèles ni placer un LLM partout. Une même référence peut couvrir plusieurs opérations. Chaque modèle supplémentaire doit justifier sa complexité d’exploitation.
Sur l’exemple d’un agent d’explication de facture : une API récupère les montants, puis du code vérifie les calculs, et un modèle rédige ensuite l’explication. Une contestation ambiguë appelle une clarification ou un transfert humain. Expliquer une facture ne donne pas le droit de la modifier.
« La réussite, les erreurs critiques, les reprises et la latence sont mesurées au 95e percentile et sous charge. »
David Guede, Partner Data et IAConverteo
Un prototype développé avec un modèle capable et autorisé peut servir de référence. Des configurations plus économiques sont ensuite testées, en intégrant le travail d’adaptation des prompts et du contexte. La descente en gamme constitue une hypothèse à valider, non une obligation.
La comparaison des candidats doit s’effectuer sur les mêmes cas, données et outils. Les prompts sont adaptés à chacun, en documentant les réglages et les budgets. La réussite, les erreurs critiques, les reprises et la latence sont mesurées, notamment au 95e percentile et sous charge. La répétition des essais permet d’apprécier la variabilité. Pour un agent, la vérification porte sur les appels d’outils et l’état final du système, et non uniquement sur la réponse produite. Rejouer le parcours complet garantit qu’un gain local n’accroît pas les échecs en aval.
Après écartement des configurations qui échouent aux critères bloquants, le coût complet par tâche réussie est calculé : coût total du flux, échecs, reprises et interventions humaines comprises, divisé par le nombre de tâches résolues conformément aux exigences. Le suivi du taux de résolution autonome complète cette analyse.
Ce coût est mis en regard de la valeur effectivement créée face au processus existant : temps libéré, erreurs évitées, service rendu.
4. Diagnostiquer l’échec avant de changer de modèle
Lorsqu’une information manque, l’accès aux données et le contexte doivent être vérifiés. Si une consigne est mal suivie, le prompt et les exemples nécessitent d’être retravaillés. En cas d’échec d’un calcul, la délégation de cette opération à du code doit être testée. Si une demande reste ambiguë, une étape de clarification est à prévoir.
Si la limite provient du modèle, plusieurs leviers sont à comparer : l’augmentation du budget de raisonnement (lorsque cela est possible), la montée en gamme, le changement de famille ou le redécoupage de la tâche.
Pour une tâche bien définie, des exemples annotés peuvent justifier un ajustement des poids (fine-tuning) sur un modèle compatible. Son gain est alors évalué au regard du coût des données, de l’entraînement et du maintien. Le diagnostic détermine le remède.
L’étape et le parcours sont réévalués après chaque modification. Si aucune configuration admissible ne satisfait les exigences, il convient de réduire l’autonomie ou de maintenir une intervention humaine.
5. Gouverner les configurations et leurs changements
La gouvernance doit porter sur la configuration complète, et non sur le seul nom du modèle. Un registre centralisé doit relier chaque usage à un responsable, une version de modèle, un hébergement, des prompts versionnés, des outils autorisés, des seuils de service et des règles de repli.
L’application des autorisations, quotas et plafonds de coût, doit être garantie par la plateforme, indépendamment du prompt.
L’orchestration choisit parmi les configurations autorisées et cette décision est tracée. Un modèle de secours doit respecter les mêmes exigences de traitement des données. Sans repli conforme, le passage en mode dégradé validé ou la suspension de l’action s’imposent. Une panne n’autorise pas le contournement de la politique de sécurité.
Tout changement de modèle, prompt, outil ou routage implique de rejouer les tests de l’étape et du parcours. Un déploiement progressif ainsi qu’une procédure de retour arrière doivent être prévus. Il convient de distinguer les tests de non-régression de la surveillance du trafic réel. Les contrôles déterministes, l’échantillonnage humain et si pertinent, un juge automatique, calibré sur l’évaluation humaine, gagnent à être combinés.
Une supervision commune de la qualité, du coût et de la latence doit aussi être organisée : seuils d’alerte, traces protégées et rejouables sans effets métier, coupe-circuit, responsabilités d’intervention. Les responsables définissent les politiques ; la plateforme applique les contrôles et en conserve les preuves.
Conclusion
En conclusion, le choix durable ne repose pas sur le nom d’un modèle. Il réside dans la capacité à expliquer pourquoi une configuration est autorisée, à démontrer qu’elle répond à la tâche et à savoir quand la remplacer. Changer de modèle devient alors une évolution maîtrisée, plutôt qu’un nouveau pari d’architecture.
Ce conseil est signé d’un professionnel de l’IT, dans le cadre d’une collaboration éditoriale que LeMagIT entretient avec des experts de l’écosystème numérique B2B. Il ne s’agit ni d’un publireportage ni d’un contenu sponsorisé : aucune rémunération n’a été versée ni perçue pour sa publication. Nous faisons appel à des praticiens du secteur pour partager leur expertise avec nos lecteurs, eux-mêmes professionnels de l’IT. La rédaction garde la totale maîtrise des sujets traités.
Pour approfondir sur Data Sciences, Machine Learning, Deep Learning, LLM
