Choisir un prestataire IA en 2026 : ce que valent les certifications, et les cinq questions qui les remplacent

---

title: "Choisir un prestataire IA en 2026 : ce que valent les certifications, et les cinq questions qui les remplacent" seoTitle: "Prestataire IA : ce que valent les certifications" description: "Les agences IA affichent désormais des certifications nominatives sur les modèles. Voici ce que ces examens mesurent réellement, les cinq angles morts qu'ils laissent entiers, et les questions d'entretien qui séparent un prestataire qui livrera d'un prestataire qui facturera." seoDescription: "Ce que les certifications d'agence IA attestent vraiment, et les cinq questions d'entretien qui prédisent mieux la réussite d'un projet." date: "2026-09-27" author: "Équipe Raicode" tags: ["IA", "automatisation", "gestion de projet", "audit"] category: "IA & Automatisation" keywords: ["choisir un prestataire IA", "agence IA sur mesure", "certification IA agence", "expert Claude certifié", "questions à poser prestataire IA", "sélectionner agence intelligence artificielle", "audit prestataire IA", "prestataire LLM entreprise"]

Vous avez trois propositions sur le bureau pour la même fonctionnalité IA. La première vient d'un freelance qui a livré deux projets comparables et dont vous n'avez aucune preuve extérieure. La deuxième vient de votre intégrateur habituel, qui n'a jamais mis un LLM en production mais qui connaît votre système d'information. La troisième vient d'une agence dont la page d'accueil annonce des architectes certifiés sur le modèle que vous comptez utiliser, avec les badges, les noms et les dates. À prix comparable, la troisième a l'air d'être le choix prudent.

C'est exactement à ce moment-là qu'il faut ralentir. Depuis un an, la certification nominative sur un modèle est devenue l'argument de différenciation principal des agences IA françaises les mieux référencées. L'argument fonctionne parce qu'il répond à une angoisse réelle — comment juger une compétence qu'on n'a pas soi-même — et parce qu'il n'a, pour l'instant, aucun contradicteur. Il mérite pourtant d'être examiné, parce que sa corrélation avec la réussite d'un projet IA en production est beaucoup plus faible que son apparence ne le suggère.

Cet article n'est pas un procès des certifications. Elles attestent quelque chose de réel. Le problème est que ce quelque chose n'est presque jamais ce qui fait échouer les projets qu'on nous demande de reprendre.

Ce qu'une certification atteste réellement

Les certifications proposées par les éditeurs de modèles évaluent, à quelques variantes près, le même périmètre : la connaissance de l'API et de ses paramètres, les schémas de prompt qui fonctionnent, l'usage des outils et de l'appel de fonctions, les mécanismes de récupération documentaire proposés par la plateforme, les bonnes pratiques de sécurité affichées par l'éditeur, et la lecture correcte de la facturation par jetons. L'examen dure quelques heures, il est majoritairement à choix multiples, parfois complété d'un exercice pratique court.

Trois propriétés découlent de ce format, et elles comptent plus que le contenu.

L'examen est conçu par le fournisseur, et il évalue sa plateforme. Un architecte certifié sur un modèle connaît les capacités de ce modèle, ses garde-fous et ses arguments commerciaux. Rien dans l'examen ne l'entraîne à conclure que votre cas d'usage ne justifie pas d'appeler ce modèle — que la moitié de vos requêtes se résout avec une règle métier, un index plein texte ou un modèle dix fois moins cher. C'est pourtant l'arbitrage qui fait le plus de différence sur la facture à douze mois.

L'examen porte sur la construction, pas sur l'exploitation. Il vérifie qu'on sait assembler une chaîne de récupération documentaire correcte. Il ne vérifie pas qu'on sait détecter, trois semaines après la mise en ligne, que le taux de réponses hors sujet est passé de 4 à 11 % parce qu'un métier a ajouté deux cents documents mal formatés dans la base source. Or c'est là que se situe la difficulté réelle, et c'est le sujet de la quasi-totalité des reprises qu'on nous confie.

La certification est nominative, le contrat ne l'est pas. C'est le décalage le plus concret et le plus facile à vérifier. La personne certifiée figure sur le site de l'agence. Elle ne figure pas nécessairement sur votre projet, ou seulement en avant-vente et en comité de pilotage. Le code, lui, sera écrit par une équipe dont vous ne connaissez ni la composition ni l'expérience. Cette question n'est pas propre à l'IA — elle se pose pour choisir une agence MVP ou SaaS exactement de la même manière — mais elle est plus coûteuse ici, parce que les erreurs d'architecture d'un système à base de LLM ne se voient pas à la recette.

Une certification est donc un signal de sérieux dans l'apprentissage, au même titre qu'une certification cloud. Elle dit que quelqu'un, dans la structure, a investi du temps à comprendre une plateforme. C'est mieux que rien. Ce n'est pas une garantie de livraison, et ce n'est surtout pas un substitut à la vérification que vous devez mener vous-même.

Les cinq angles morts que l'examen laisse entiers

Si l'on reprend les projets IA arrivés chez nous en mauvais état, les causes se rangent dans cinq catégories. Aucune n'est couverte par un examen de certification.

Le coût réel par interaction. Un prototype qui coûte 0,04 € par requête paraît négligeable en démonstration. À 30 000 requêtes mensuelles, il pèse 1 200 € par mois, et il en pèsera le double dès que quelqu'un ajoutera un historique de conversation ou un second passage de vérification. Beaucoup d'équipes découvrent la courbe au troisième mois de production. Les mécanismes qui la redressent — mise en cache des préfixes, routage vers un modèle plus petit sur les cas simples, traitement par lots de ce qui n'est pas temps réel, réduction du contexte injecté — relèvent de l'ingénierie de production et pas du programme d'examen. Nous avons détaillé ailleurs comment reprendre en main une facture d'API qui s'emballe.

La définition de la qualité. Dans la grande majorité des reprises, personne n'a jamais écrit ce qu'était une bonne réponse. Il n'existe ni jeu de cas de référence, ni score historisé, ni seuil d'acceptation. Conséquence directe : aucune modification ne peut être jugée. On change un prompt, on regarde trois exemples, on décide au ressenti, et on découvre la régression par une remontée client six semaines plus tard.

L'exploitation. Pas de trace des appels, pas d'échantillonnage des réponses, pas d'alerte sur la latence ni sur le taux d'échec d'outil, pas de procédure de retour arrière quand un changement de version du modèle dégrade le comportement. Le système marche le jour de la livraison, puis dérive en silence.

Le traitement des données et la conformité. Où partent les documents, quelle rétention chez le fournisseur, quelle base légale pour les données personnelles injectées dans les prompts, que fait-on des entrées utilisateur qui contiennent des instructions hostiles. Ces questions arrivent presque toujours après la mise en production, quand elles bloquent le déploiement à l'échelle.

La reprise par un tiers. Le système est-il reconstructible sur un poste neuf, à partir du dépôt, en moins d'une journée ? Les index sont-ils régénérables par un script ou ont-ils été construits à la main ? Les clés appartiennent-elles à vos comptes ou à ceux du prestataire ? C'est le critère qui décide de votre liberté dans dix-huit mois, et il ne figure dans aucune grille d'évaluation commerciale.

Ces cinq angles morts ont un point commun : ils sont invisibles à la recette et visibles dans la facture, dans les tickets support ou dans le devis de reprise. C'est la raison pour laquelle notre offre de reprise de projet IA commence par les mesurer avant toute discussion sur le code lui-même — et c'est aussi la grille que vous pouvez appliquer avant de signer, plutôt qu'après.

Les cinq questions qui les remplacent

Ces questions se posent en entretien, elles prennent quarante-cinq minutes, et elles demandent des réponses vérifiables. Une réponse générale à l'une d'elles vaut une réponse négative.

1. « Montrez-moi comment vous avez mesuré la qualité sur votre dernier projet livré »

C'est la question la plus discriminante des cinq, et de loin. Demandez à voir l'artefact : le fichier de cas de test, le script qui les rejoue, le chiffre et sa date. Peu importe que le score soit de 78 ou de 94 % — ce qui compte est que le chiffre existe, qu'il soit reproductible et qu'il ait été suivi dans le temps.

Une équipe qui a cet artefact vous le montre en deux minutes, généralement avec une anecdote sur le cas tordu qui l'a fait chuter de dix points. Une équipe qui ne l'a pas vous parlera de tests utilisateurs, de retours positifs du métier et de la qualité perçue. Ce n'est pas de la mauvaise foi : c'est le symptôme d'une culture de démonstration plutôt que de production. Si vous voulez savoir à quoi ressemble ce que vous devez exiger, le jeu d'évaluation qui manque à la plupart des agents IA en décrit la construction complète.

2. « Quel est le coût par interaction de votre dernier projet, et comment l'avez-vous fait baisser ? »

La première moitié de la question teste la mesure, la seconde teste l'ingénierie. Un prestataire qui a exploité un système en production connaît son coût unitaire à l'ordre de grandeur près, parce que quelqu'un le lui a demandé. Il a aussi, presque toujours, une histoire de division par trois ou par cinq : un modèle plus petit branché sur les cas simples, une mise en cache qui a supprimé la réinjection d'un contexte de huit mille jetons à chaque tour, un traitement nocturne qui a sorti 60 % du volume du temps réel.

Une réponse du type « cela dépend beaucoup des volumes » sans aucun chiffre signifie que la question ne s'est jamais posée, donc que le système n'a jamais tenu un volume sérieux.

3. « Qu'est-ce qui a cassé en production sur votre dernier projet, et combien de temps avant que vous le sachiez ? »

Tout système à base de modèle dérive. Les sources documentaires changent, les utilisateurs inventent des usages, les fournisseurs font évoluer leurs versions. La question ne cherche pas à savoir si quelque chose a cassé — c'est acquis — mais quel dispositif l'a révélé et en combien de temps.

Les bonnes réponses sont précises et un peu embarrassées : une alerte sur le taux d'échec d'un outil, un échantillonnage quotidien relu par une personne du métier, un tableau de bord où la latence a doublé avant que qui que ce soit ne se plaigne. Les mauvaises réponses sont rassurantes : « nous n'avons pas eu d'incident ». Sur un système exploité depuis plus de six mois, cela veut presque toujours dire que personne ne regarde.

4. « Que se passe-t-il si nous arrêtons après la première phase ? »

Cette question porte sur la réversibilité, et elle se pose avant la signature, jamais après. Trois points concrets à faire écrire dans le contrat : les comptes chez le fournisseur de modèle, l'hébergeur et la base vectorielle sont ouverts à votre nom dès le premier jour, et le prestataire y est invité — pas l'inverse. Les prompts, les jeux d'évaluation, les scripts de préparation des données et les procédures de reconstruction des index font partie des livrables, au même titre que le code. Et le système doit être reconstructible sur un poste neuf par un tiers, documentation à l'appui, ce qui se vérifie une fois, à la recette, en chronométrant.

Un prestataire solide considère ces demandes comme normales et les propose souvent lui-même. Un prestataire qui les traite comme un signe de défiance vous renseigne utilement sur la suite.

5. « Qui écrit le code, et qui sera là dans six mois ? »

Demandez les prénoms, le taux d'affectation réel et l'expérience IA de chacun, pas celle de la structure. Demandez qui assure la maintenance une fois le projet livré, et sous quel contrat. Si la personne certifiée que vous avez rencontrée en avant-vente n'apparaît pas dans l'équipe de réalisation, ce n'est pas rédhibitoire, mais cela veut dire que la certification affichée sur le site ne concerne pas votre projet. Autant le savoir avant.

Les réponses qui doivent faire arrêter la discussion

Quatre signaux, par ordre de gravité décroissante.

« Le modèle s'améliore tout le temps, ce genre de problème va disparaître. » C'est l'aveu qu'on compte sur le fournisseur pour résoudre un problème d'ingénierie. Les modèles progressent, mais la dérive des données, le coût unitaire et l'absence de mesure ne se corrigent pas tout seuls.

Un devis forfaitaire sur un système à base de LLM sans phase de cadrage mesurée. Personne ne peut chiffrer honnêtement une fonctionnalité dont le taux de réussite sur vos données réelles n'a pas été estimé. Un forfait ferme sur ce périmètre signifie soit une marge de sécurité énorme, soit une découverte douloureuse à mi-parcours.

Aucune question sur vos données pendant l'entretien. Un prestataire expérimenté demande très tôt le volume, le format, la qualité, les droits et la manière dont les documents sont produits. Celui qui ne pose pas ces questions n'a pas encore rencontré le moment où elles décident de tout.

Le refus de vous laisser parler à un client en production. Pas une référence commerciale écrite : un appel de vingt minutes avec quelqu'un qui exploite le système depuis six mois. Une seule question suffit à cette personne : « qu'est-ce que vous vérifiez à la main derrière ? »

Le test qui vaut mieux que les cinq questions

Quand l'enjeu dépasse quelques dizaines de milliers d'euros, il existe une vérification plus fiable que n'importe quel entretien : acheter une semaine de cadrage, payée, à deux prestataires en parallèle, avec un livrable identique et imposé. Un taux de réussite mesuré sur cinquante cas réels tirés de vos données, un coût par interaction projeté à douze mois, une architecture cible en une page, et la liste des risques avec leur coût de traitement.

Une semaine facturée chez deux prestataires coûte entre six et douze mille euros. C'est le prix d'un mois de développement dans la mauvaise direction, et cela vous apprend ce qu'aucune certification ne peut dire : comment ces gens travaillent réellement sur vos données, ce qu'ils osent vous annoncer comme mauvaise nouvelle, et à quoi ressemble un document qu'ils produisent quand ils sont payés pour être précis. C'est la même semaine que celle décrite dans l'audit de reprise d'un projet IA, à ceci près qu'elle porte ici sur un système qui n'existe pas encore.

Les deux livrables se comparent en une heure. L'écart entre eux est en général spectaculaire, et il ne recoupe presque jamais l'ordre des badges affichés sur les pages d'accueil.

Ce qu'il faut retenir avant de signer

Une certification atteste qu'une personne, à une date donnée, a démontré sa connaissance d'une plateforme. C'est un signal positif et mineur. Ce qui prédit la réussite de votre projet tient dans quatre preuves matérielles, toutes vérifiables en entretien : un jeu d'évaluation existant sur un projet passé, un coût unitaire connu et une histoire de réduction, un dispositif de surveillance qui a déjà révélé un incident, et une clause de réversibilité acceptée sans discussion.

L'action concrète pour cette semaine : reprenez les propositions que vous avez reçues et demandez à chaque prestataire, par écrit, les deux premiers éléments — l'artefact d'évaluation et le coût par interaction du dernier projet livré. Le délai de réponse et la précision des chiffres trieront votre liste plus sûrement que n'importe quelle grille de notation.

Et si vous avez déjà signé, que le système tourne et que vous n'êtes sûr d'aucun de ces quatre points, la vérification se mène de l'extérieur en quelques jours — c'est exactement le travail que nous faisons le plus souvent.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.