Les 7 questions à poser avant de signer avec un prestataire IA

Un projet d’intelligence artificielle rate rarement sur la technique. Il rate parce que les données n’étaient pas où on croyait, parce que personne n’a prévu le comportement du système quand il se trompe, parce que la facture mensuelle de fonctionnement n’avait pas été chiffrée, ou parce que l’outil livré n’a jamais été utilisé par les gens à qui il était destiné. Ces quatre causes se voient toutes avant la signature, à condition de poser la question qui les découvre.

Les sept questions ci-dessous sont classées dans l’ordre où elles font le plus de dégâts si la réponse manque. Chacune vient avec ce qu’une bonne réponse contient, et avec le signal qui doit vous faire ralentir. Elles valent pour un indépendant comme pour une agence — le choix entre les deux se fait avant, sur d’autres critères.

La plupart des prestations IA font sortir vos données de chez vous : elles passent par l’interface de programmation d’un éditeur de modèle — Anthropic, OpenAI, Mistral, Google — hébergée quelque part, exploitée selon des conditions que vous n’avez pas signées. Ce n’est pas un problème en soi. C’en devient un quand personne ne sait le dire.

Une bonne réponse contient le nom de l’éditeur du modèle, la région d’hébergement, la durée de conservation, la mention explicite de savoir si vos contenus servent ou non à entraîner le modèle — sur les offres professionnelles des grands éditeurs, ils ne servent généralement pas —, et la liste des sous-traitants qui interviennent au passage.

Le signal d’alarme : « c’est sécurisé », « c’est hébergé chez nous », sans qu’aucun nom ne soit prononcé. Beaucoup d’outils vendus comme maison sont des surcouches revendues ; l’ignorer, c’est découvrir en cours de projet que vos documents transitent par un quatrième acteur dont vous n’aviez jamais entendu parler.

Ce n’est pas une demande de références au sens commercial. C’est une demande de livraison comparable : un système du même type, en service, chez quelqu’un, depuis assez longtemps pour qu’on sache ce qu’il a changé.

Une bonne réponse contient un nom de client, ou — si un accord de confidentialité l’interdit — une démonstration en direct sur un cas réel, avec la date de mise en service, le nombre de personnes qui s’en servent, et ce qui a été mesuré depuis. Un prestataire qui a livré sait dire ce qui n’a pas marché la première fois.

Le signal d’alarme : des captures d’écran, une étude de cas sans nom, une démonstration construite pour le rendez-vous. Notre annuaire publie 170 fiches ; sur les 153 que nous avons collectées jusqu’au 1er septembre 2026, 18 affichent au moins une référence client nommée — nous ne l’écrivons que lorsque le prestataire l’affiche lui-même publiquement, jamais sur déclaration. C’est exactement le niveau de preuve que vous pouvez exiger.

Un système bâti sur un modèle de langage se trompe. Pas parfois : par construction. La question n’est donc jamais « est-ce que ça se trompe », mais « qu’est-ce qui est prévu quand ça arrive ». C’est la question qui distingue le plus nettement un prestataire qui a mis un système en production d’un prestataire qui a fait des démonstrations.

Une bonne réponse contient un taux d’erreur mesuré sur un jeu de cas de test que vous pouvez relire, le comportement prévu en cas de doute — passer la main à un humain, refuser de répondre, signaler l’incertitude plutôt que l’inventer —, et qui surveille tout cela une fois le projet livré.

Le signal d’alarme : « notre modèle ne se trompe pas », ou « on a un prompt très solide ». La deuxième formule est plus inquiétante que la première : elle confond le réglage d’une consigne avec un dispositif de contrôle.

Le devis chiffre la construction. Il ne chiffre presque jamais ce que coûte le système ensuite : la consommation de l’interface de programmation, l’hébergement, la surveillance, et la reprise à faire quand l’éditeur du modèle sort une version qui change le comportement. Sur les projets qui dérapent, c’est la ligne qu’on découvre au troisième mois.

Une bonne réponse contient un coût mensuel estimé avec l’hypothèse de volume qui va avec, et ce que devient ce coût si le volume double. Notre simulateur de budget sépare justement les deux lignes ; en régie, le repère de tarif journalier va de 300 à 700 € HT selon la séniorité, détaillé dans notre baromètre des TJM.

Le signal d’alarme : un devis de construction sans aucune ligne de fonctionnement, ou un forfait mensuel « tout compris » dont personne ne sait dire ce qu’il comprend.

Un projet IA laisse derrière lui du code, des consignes rédigées, parfois un modèle ajusté sur vos données, et une série de comptes ouverts chez des éditeurs. Savoir à qui tout cela appartient est une question de contrat, pas de confiance — et elle se pose avant, parce qu’après, elle se pose en position de faiblesse.

Une bonne réponse contient : c’est écrit dans le contrat, les comptes chez les éditeurs sont ouverts à votre nom, et il existe une procédure de sortie — export des données, remise du code, transfert des accès — que le prestataire sait décrire sans hésiter.

Le signal d’alarme : les comptes sont au nom du prestataire, le travail vit « sur notre plateforme », et aucun export n’est prévu. Vous ne louez plus un service : vous devenez dépendant d’un intermédiaire pour accéder à vos propres données.

La cause d’échec la plus fréquente n’est pas technique. C’est un outil qui fonctionne et que personne n’ouvre, parce qu’il a été conçu avec la direction et livré à des équipes qui n’en avaient pas entendu parler. Un prestataire qui ne pose jamais la question de l’usage vend une livraison, pas un résultat.

Une bonne réponse contient les métiers concernés nommés, une formation prévue et chiffrée dans la proposition, et une manière de constater l’adoption à trois mois — nombre d’utilisateurs actifs, temps réellement gagné, n’importe quoi de comptable. La formation des équipes est un livrable à part entière, pas une politesse de fin de projet.

Le signal d’alarme : le calendrier s’arrête à la livraison.

C’est la question la plus courte et la plus révélatrice. Un prestataire qui exerce depuis un moment a refusé des demandes : parce que l’IA n’était pas le bon outil, parce que les données n’existaient pas, parce que le budget ne permettait pas de faire les choses correctement. S’il n’a jamais rien refusé, deux hypothèses seulement — il débute, ou il accepte tout.

Une bonne réponse contient un cas précis, avec la raison du refus. Les meilleures réponses commencent souvent par « on nous demande souvent ça, et on dit non parce que… ».

Le signal d’alarme : « on sait tout faire ». Personne ne sait tout faire, et l’IA est précisément le domaine où on vous le promettra le plus volontiers.

« Quel modèle utilisez-vous ? » Elle sonne technique, elle rassure celui qui la pose, et elle n’apprend presque rien. Les modèles changent tous les quelques mois, un bon prestataire en change quand c’est justifié, et le nom du modèle ne dit rien de la qualité de ce qui est construit autour — qui est l’essentiel du travail. La question utile, si le sujet vous intéresse, est celle du numéro 1 : qui est l’éditeur, et où vont les données.

Si votre projet porte sur la visibilité — référencement naturel, citation dans les réponses de ChatGPT ou de Perplexity — six autres questions s’y ajoutent, propres à ce métier : nous les avons détaillées dans notre décryptage de l’expression « agence SEO IA ».

1. Où vont mes données, et qui peut les lire ?
2. Montrez-moi la même chose, déjà livrée ailleurs.
3. Que se passe-t-il quand ça se trompe ?
4. Combien ça coûte à faire tourner, une fois livré ?
5. Qui possède ce qui est construit, et comment je reprends la main ?
6. Qui va s’en servir, et qui les forme ?
7. Qu’est-ce que vous refusez de faire ?

Posées dans cet ordre, elles tiennent dans un premier rendez-vous. Celle qui reste sans réponse en dit plus que les six autres réunies.