Agence agent IA : comparer les propositions et les livrables

Vous recevez trois propositions d'agence agent IA pour le même besoin, avec un périmètre annoncé identique, et les prix s'étalent du simple au double. La différence ne se joue pas sur le périmètre écrit, mais sur les preuves exigées, les clauses de réversibilité et les coûts récurrents que chaque document laisse dans le flou. Ce guide vous donne une méthode de comparaison ligne à ligne, avec des exemples de clauses concrètes et les signaux faibles qui doivent vous alerter. Tout ce qui suit s'appuie sur trois propositions fictives, construites pour l'exercice, jamais sur des cas observés.

Le principe : un périmètre identique ne garantit rien

Deux propositions peuvent décrire exactement le même agent — un assistant qui prépare des réponses e-mail et crée des événements d'agenda — et produire des résultats très différents. La première exigera des démonstrations sur données fictives avant signature ; la seconde se contentera d'une maquette d'écran. Le périmètre fonctionnel est le même, la capacité réelle de l'agence à le livrer ne se voit pas dans la description.

C'est pourquoi votre comparaison doit porter sur ce que chaque proposition s'engage à prouver, pas sur ce qu'elle promet. Un bon réflexe consiste à partir d'un cahier des charges testable rédigé avant la mise en concurrence : si les trois agences répondent au même document, les écarts qui apparaissent dans leurs réponses deviennent de vrais signaux de comparaison.

Les trois propositions fictives de référence

Pour rendre la méthode concrète, voici trois propositions hypothétiques, notées A, B et C, toutes trois pour le même agent : rédaction de brouillons de réponse e-mail, création d'événements d'agenda à partir de ces échanges, et un tableau de bord de suivi. Prix fictifs : A propose 28 000 € de forfait plus 900 € par mois, B propose 41 000 € plus 350 € par mois, C propose 33 000 € plus 1 400 € par mois.

À première vue, A semble la moins chère et C la plus chère en récurrent. Mais la proposition A ne mentionne aucun compte de test, aucune reprise de données et aucun engagement de support au-delà d'une phrase vague. B inclut une phase de preuve sur données fictives et un plan de réversibilité détaillé. C chiffre les coûts d'usage mais ne dit rien de la propriété du code. Le classement réel dépend donc des clauses, pas du prix affiché.

Exiger des preuves sur données fictives

Le premier critère de comparaison est la nature de la preuve demandée avant engagement, ou en phase initiale. Une démonstration sur les données de démonstration du fournisseur prouve que l'agence sait faire une démo. Une preuve sur vos données fictives — des e-mails anonymisés, des agendas de test, des cas limites que vous avez choisis — prouve qu'elle peut traiter votre réalité.

Comparez explicitement ce que chaque proposition prévoit :

• Jeu de données : qui fournit les cas de test, combien de cas limites sont inclus, et qui valide qu'ils sont représentatifs.
• Environnement : les preuves se font-elles dans un environnement isolé, avec des comptes de test distincts de vos comptes de production ?
• Critères de réussite : la proposition fixe-t-elle des critères mesurables, ou seulement une livraison ?

Une proposition qui refuse la preuve sur données fictives, ou qui la facture comme une option coûteuse, vous signale qu'elle préfère être jugée sur sa présentation plutôt que sur son résultat. C'est un signal faible, pas une disqualification automatique — mais il doit être discuté en réunion, pas laissé dans le document.

La liste des comptes et les permissions réelles

Deuxième critère : chaque proposition doit lister les comptes et accès nécessaires, avec le niveau de permission exact. C'est là que les descriptions floues coûtent le plus cher. Un exemple concret tiré de l'écosystème Gmail : les scopes gmail.compose et gmail.modify peuvent tous deux autoriser l'envoi de messages. Si votre besoin est « préparer des brouillons, jamais envoyer », un libellé de scope ne suffit pas comme garantie : la limitation aux brouillons doit être un contrôle applicatif, testé et documenté. Un libellé n'est pas une frontière de permission Gmail.

Comparez donc les propositions sur ce point précis. Si l'agence A écrit « connexion Gmail en lecture-écriture » sans plus de détail, et l'agence B écrit « création de brouillons uniquement, envoi bloqué au niveau applicatif, test de non-envoi inclus dans la recette », vous avez deux niveaux de maturité très différents pour un périmètre identique. Même logique pour les identifiants : l'identifiant d'un brouillon Gmail est stable, mais l'identifiant du message qu'il contient change à chaque modification — une agence qui a réellement travaillé sur ce cas le sait et le mentionne dans sa gestion des versions, celle qui n'a jamais implémenté ce flux le découvrira à vos frais.

Propriété du code, confidentialité et données

Troisième bloc de comparaison : qui possède quoi à la fin. La proposition doit répondre sans ambiguïté à trois questions. Le code spécifique développé pour vous vous appartient-il, ou est-il sous licence ? Les configurations, prompts et règles métier sont-ils exportables dans un format lisible ? Vos données transitent-elles par des services tiers, et lesquels ?

Sur la confidentialité, méfiez-vous des propositions qui se limitent à « nous appliquons le RGPD ». Demandez la liste des sous-traitants et des transferts hors Union européenne, et le sort des données à la fin du contrat. Les grands principes de protection des données — minimisation, durée de conservation, sécurité — donnent un cadre simple pour évaluer les réponses : une proposition qui ne sait pas dire où dorment vos données la nuit n'a pas fait le travail. Dans nos trois propositions fictives, A ne mentionne aucun sous-traitant, B les liste avec les pays d'hébergement, C renvoie à « la politique de confidentialité de nos partenaires » sans les nommer. Seule B vous permet de vérifier quelque chose.

Responsabilités, acceptation et critères de recette

La clause d'acceptation est celle qui décide de qui porte le risque en fin de projet. Une bonne clause définit des critères objectifs, une procédure de test, un délai de correction et une conséquence en cas d'échec répété. Une mauvaise clause dit « le client valide la livraison » — ce qui transfère tout le poids de la preuve sur vous.

Comparez les propositions sur quatre points :

1. Critères d'acceptation : sont-ils chiffrés et testables, ou descriptifs ? « L'agent prépare des brouillons corrects » n'est pas testable ; « sur les 30 cas du jeu de test, au moins 27 brouillons jugés utilisables sans réécriture majeure par deux évaluateurs » l'est.
2. Procédure de recette : existe-t-il un document de recette séparé, avec un calendrier et un traitement des réserves ? Un guide sur la recette et la livraison d'un chatbot peut vous servir de grille pour juger la qualité de ce que chaque agence propose.
3. Responsabilités : que se passe-t-il si l'agent envoie un e-mail erroné ou crée un événement en double ? La proposition doit distinguer la défaillance du logiciel, l'erreur d'usage et le cas de force majeure.
4. Plafonds : y a-t-il un plafond de responsabilité, et est-il cohérent avec le prix du marché ?

Un point technique souvent révélateur : la synchronisation d'agenda. L'API Calendar permet de créer des événements avec des identifiants explicites, mais il n'existe pas de transaction globale garantie entre votre système et l'agenda. Une agence qui prétend une « synchronisation garantie à 100 % » sans expliquer sa stratégie de reprise après échec, ou bien n'a pas compris le problème, ou bien ne vous le dit pas. Demandez comment elle gère un événement créé côté agenda mais dont la confirmation côté votre système a échoué.

Réversibilité : la clause qui protège votre avenir

La réversibilité est le critère le plus négligé et le plus déterminant sur trois ans. Elle répond à une question simple : si vous changez d'agence ou rapatriez le projet en interne, que récupérez-vous, sous quelle forme, et à quel coût ?

Une clause de réversibilité sérieuse précise : la remise du code et de sa documentation, l'export des configurations et règles métier, la restitution des données dans un format documenté, un accompagnement à la transition d'une durée définie, et l'absence de pénalité de sortie. Elle précise aussi ce qui reste chez l'agence : les composants génériques qu'elle réutilise chez d'autres clients peuvent légitimement rester sa propriété, à condition que votre projet fonctionne sans eux ou avec une licence de continuation.

Dans nos propositions fictives, B inclut un plan de réversibilité de dix pages avec un test de restauration ; A mentionne « remise des sources sur demande » ; C prévoit une « indemnité de sortie égale à trois mois d'honoraires ». Aucune de ces formulations n'est illégale, mais elles créent des positions de négociation très différentes. Une agence confiante dans la qualité de sa livraison n'a rien à craindre d'une clause de réversibilité précise.

Support, maintenance et coûts récurrents

Le coût réel d'un agent ne se lit pas dans le forfait initial mais dans la somme des coûts récurrents sur deux ou trois ans. Comparez les propositions sur une grille commune : hébergement, licences d'API et de modèles, consommation liée au volume, maintenance corrective et évolutive, astreinte, et révisions tarifaires.

Deux pièges reviennent systématiquement. Premier piège : la consommation d'API facturée au volume, dont personne n'a chiffré le scénario haut. Demandez à chaque agence une estimation pour trois scénarios — faible, nominal, pointe — avec la formule de calcul. Un guide sur le budget réel d'utilisation d'un agent vous aide à construire ces scénarios et à repérer les propositions qui n'ont pas fait le calcul. Deuxième piège : la facturation par canal. Si votre agent envoie des notifications WhatsApp, la tarification de la plateforme se fait par message livré, avec des catégories et des marchés différents, et tous les messages ne sont pas payants — une proposition qui applique un tarif forfaitaire unique par message soit ignore ce mécanisme, soit se ménage une marge invisible.

Le support se compare aussi sur des éléments vérifiables : horaires de prise en charge, délai de réponse contractuel, distinction entre incident et demande d'évolution, et ce qui déclenche un devis supplémentaire. « Support inclus » sans définition signifie que tout ce qui n'est pas un bug sera facturé.

Analyse de clauses concrètes et signaux faibles

Au-delà des grands blocs, la comparaison se joue dans le détail des formulations. Voici des clauses fictives typiques et ce qu'elles révèlent.

Clause	Formulation observée (fictive)	Ce qu'elle suggère	Conduite à tenir
Preuve	« Démonstration sur notre environnement de démo »	L'agence évite vos cas limites	Exiger un jeu de test sur vos données fictives
Permissions	« Accès complet à la boîte e-mail »	Aucun contrôle applicatif prévu	Demander le principe de moindre privilège, testé
Propriété	« Le livrable reste la propriété de l'agence »	Dépendance durable non chiffrée	Négocier une licence perpétuelle ou la cession
Acceptation	« Validation à la livraison par le client »	Risque entièrement sur vous	Proposer des critères chiffrés du cahier des charges
Réversibilité	« Indemnité de sortie de 3 mois »	Coût de départ dissuasif	Plafonner ou supprimer, prévoir le test de restauration
Support	« Support réactif inclus »	Aucun engagement mesurable	Définir délais, horaires, périmètre contractuel
Récurrent	« Frais de plateforme selon usage »	Scénario haut non chiffré	Exiger trois scénarios avec formule de calcul

Trois signaux faibles méritent une attention particulière. D'abord, l'absence de liste de comptes : une agence qui ne sait pas dire de quels accès elle a besoin n'a pas encore conçu le système. Ensuite, la confusion entre protocole et règles métier : le protocole MCP, par exemple, permet d'échanger des outils et du contexte avec un modèle, mais il ne choisit pas à votre place les règles métier ni les permissions — une proposition qui présente « MCP » comme la réponse à une question de gouvernance confond le tuyau et la décision. Enfin, la preuve d'identité par raccourci : un QR code à scanner pour « connecter votre agent WhatsApp » ne prouve pas une connexion officielle à la Business Platform ; demandez le canal exact, la fenêtre de service de 24 heures et la gestion des modèles approuvés, ainsi que les conditions d'usage du canal WhatsApp Business.

Procédure de comparaison en cinq étapes

Voici une procédure directement applicable dès réception des propositions.

1. Normalisez le périmètre. Reprenez votre cahier des charges et vérifiez que les trois propositions couvrent bien les mêmes cas d'usage, les mêmes canaux et les mêmes exclusions. Reclassez toute divergence dans un tableau d'écarts avant de comparer les prix.
2. Scorez les preuves. Pour chaque proposition, notez ce qui est prouvé sur vos données fictives, ce qui est promis, et ce qui est absent. Une promesse non prouvable n'a pas de valeur dans la comparaison.
3. Chiffrez le total à trois ans. Additionnez forfait, récurrent contractuel, estimation de consommation aux trois scénarios, et une provision pour évolutions. Comparez ces totaux, pas les prix affichés. Un guide sur le coût complet d'un agent IA détaille les postes souvent oubliés.
4. Testez la réversibilité. Posez la même question écrite aux trois agences : « Si nous arrêtons la collaboration dans dix-huit mois, que nous remettez-vous, sous quel format, et à quel coût ? » Les réponses écrites valent mieux que les discours en réunion.
5. Vérifiez l'acceptation. Relisez la clause d'acceptation de chaque proposition et reformulez-la en critères chiffrés. Si une agence refuse vos critères, demandez les siens par écrit.

L'exemple principal : la même demande, trois réponses

Reprenons la demande initiale : brouillons d'e-mail, création d'événements d'agenda, tableau de bord. Voici comment les trois propositions fictives traitent le même point — l'envoi d'e-mail — et pourquoi l'écart compte.

La proposition A écrit : « L'agent envoie les réponses directement, avec validation humaine optionnelle. » Elle utilise un scope d'écriture large et repose la sécurité sur une case à cocher. Le jour où la validation est désactivée par un utilisateur pressé, l'agent envoie seul. La proposition B écrit : « L'agent crée des brouillons uniquement ; l'envoi est bloqué au niveau applicatif ; un test de non-envoi sur 20 cas figure dans la recette. » Le comportement est limité par construction, pas par discipline. La proposition C ne dit rien sur l'envoi ; elle décrit la rédaction et laisse la question ouverte.

Pour un périmètre identique sur le papier, ces trois formulations produisent des risques, des tests et des coûts de recette différents. C'est exactement le type d'écart que votre comparaison doit faire remonter, ligne par ligne, avant que le prix ne devienne le seul critère de décision. La même lecture s'applique à l'agenda : la proposition B précise qu'elle utilise des identifiants d'événement explicites pour permettre les mises à jour et la déduplication, là où A et C n'en parlent pas — détail qui deviendra un incident en production si votre système et l'agenda créent chacun leur version de la vérité.

Si vous souhaitez confronter cette grille de lecture à une mission concrète, vous pouvez définir votre besoin avec Edeverse.

Questions fréquentes

Une proposition plus chère est-elle forcément mieux clause ?

Non. Le prix et la qualité des clauses sont largement indépendants. Dans nos exemples fictifs, la proposition la plus chère en récurrent est celle qui laisse la propriété du code dans le flou. Jugez chaque clause sur son contenu, puis mettez le prix en regard du risque résiduel que vous acceptez de porter.

Peut-on demander une preuve sur données fictives avant de signer ?

Oui, et c'est une pratique raisonnable si le périmètre de la preuve est limité et rémunéré équitablement. Vous pouvez proposer une phase de cadrage payée, avec un jeu de données fictif que vous fournissez et des critères de réussite écrits. Une agence sérieuse accepte d'être testée sur un périmètre borné.

Que faire si une agence refuse de lister ses sous-traitants ?

Demandez au minimum les catégories de sous-traitants, les pays d'hébergement et les engagements contractuels qui vous lient. Si le refus persiste, c'est un signal faible majeur : vous ne pourrez ni évaluer les transferts de données ni exercer vos droits en cas d'incident.

Le protocole MCP est-il un argument de choix déterminant ?

C'est un élément d'architecture, pas une réponse à vos questions de gouvernance. MCP organise l'échange d'outils et de contexte, mais les règles métier, les permissions et les contrôles restent à définir et à tester. Une proposition qui fait de MCP sa seule valeur ajoutée mérite une question de suivi : que faites-vous précisément pour les permissions et la recette ?

Comment comparer des coûts récurrents quand les formules diffèrent ?

Reconstruisez vous-même le total à trois ans à partir des hypothèses de chaque proposition, avec vos propres scénarios de volume. Si une agence refuse de fournir sa formule de calcul ou ses hypothèses de consommation, chiffrez le scénario haut vous-même et intégrez-le dans la comparaison, en le signalant comme risque.