Comment choisir une agence IA : critères, preuves et signaux d’alerte

Conseil, studio produit, intégrateur ou spécialiste

Un cabinet de conseil aide à prioriser les cas d’usage et à organiser la gouvernance. Un studio produit transforme un besoin en parcours et en interface. Un intégrateur relie données, modèles et logiciels métier. Une agence spécialisée concentre son expérience sur un domaine comme la recherche documentaire, la vision, le marketing ou l’automatisation.

Pourquoi une entreprise fait appel à une agence

Le recours externe est utile pour réunir temporairement des compétences difficiles à coordonner, accélérer un pilote ou obtenir un regard indépendant. Il ne supprime pas le besoin d’un propriétaire interne capable de trancher les priorités, fournir les exemples et accepter les résultats.

Ce qui doit rester explicite dans le modèle d’intervention

Demandez ce qui sera réalisé directement, sous-traité ou laissé à votre équipe. Identifiez les personnes présentes au cadrage, celles qui construiront la solution et celles qui assureront le support. Le nom ou la taille du prestataire ne garantit pas ce modèle d’intervention.

Comprendre le processus avant de choisir la technologie

L’agence doit observer comment la tâche est accomplie aujourd’hui, y compris les contournements et les reprises manuelles. Elle peut alors distinguer un problème de données, d’interface, d’organisation ou de décision et choisir une réponse proportionnée.

• Reformuler le problème et les non-objectifs.
• Identifier la source de vérité et les exceptions.
• Nommer les utilisateurs et les personnes affectées.
• Comparer l’IA à une règle ou à un changement de processus.

Relier le cas d’usage à un objectif vérifiable

“Gagner en productivité” reste trop large. Le cadrage doit préciser le délai, la qualité, le volume, le coût ou le taux de reprise que le pilote observera. La mesure de départ et les conditions de comparaison sont définies avant le développement.

Prévoir l’accompagnement dans la durée

Le besoin ne s’arrête pas à la mise en ligne. Les données changent, les fournisseurs mettent à jour leurs modèles et les utilisateurs découvrent de nouveaux cas limites. Demandez qui suit ces changements, selon quel budget et avec quel processus de décision.

Maîtrise des modèles et des méthodes pertinentes

Demandez comment l’équipe choisit un modèle, construit un jeu d’évaluation et traite les erreurs. Une réponse solide distingue la qualité du modèle, la qualité de la recherche documentaire, les règles applicatives et le comportement de l’interface.

Expérience des systèmes RAG et des agents

Pour un projet documentaire, l’équipe doit expliquer segmentation, métadonnées, droits d’accès, citations et évaluation de la récupération. Pour un agent, elle doit aussi couvrir outils autorisés, limites d’action, journalisation, validation et arrêt. Le vocabulaire ne remplace pas ces mécanismes.

Capacité d’intégration dans votre écosystème

Une démonstration autonome n’est pas une intégration. Vérifiez l’authentification, les API, les formats de données, les quotas, les environnements de test, la reprise sur erreur et la responsabilité de chaque système.

Compétences de mise en production

Le projet doit inclure surveillance, coût, versions, incidents et maintenance. Demandez un exemple de journal, de tableau de bord, de procédure d’arrêt ou de test de non-régression plutôt qu’une promesse générale de fiabilité.

Lire une étude de cas au-delà du résultat annoncé

Recherchez la situation initiale, le périmètre exact, les données disponibles, la période, le mode de calcul et les difficultés rencontrées. Un pourcentage sans base, durée ni responsabilité attribuée ne permet pas de comparer.

Vérifier les témoignages et les logos

Un logo ne prouve ni une relation actuelle ni le rôle de l’agence. Demandez l’autorisation de publication, la nature de la mission et, lorsque cela est possible, une personne ou un livrable pouvant confirmer le travail présenté.

Accepter aussi des preuves de méthode

Une architecture commentée, un plan de test, un exemple de documentation ou le récit d’un échec corrigé peuvent être plus instructifs qu’un cas client spectaculaire. Ces éléments montrent comment l’équipe raisonne lorsque le projet sort de la démonstration.

• Situation initiale et référence.
• Périmètre exact de la mission.
• Données et contraintes.
• Résultat et méthode de mesure.
• Difficultés et corrections.
• État du service après la livraison.

Du cadrage au pilote

Le cadrage documente le processus, les données, les risques et la référence de mesure. Le prototype vérifie une hypothèse technique. Le pilote ajoute des utilisateurs et des cas représentatifs. La production exige exploitation, support et responsabilité.

Des critères d’acceptation avant la démonstration

Le corpus de test contient des cas courants, des exceptions, des entrées incomplètes et des situations à refuser. Les seuils de qualité, de coût et de délai sont versionnés pour éviter de déplacer la définition de la réussite après coup.

Un pilotage qui rend les arbitrages visibles

Chaque jalon doit présenter ce qui fonctionne, ce qui échoue, les coûts observés et les décisions attendues. Les changements de périmètre sont chiffrés et leurs effets sur la sécurité, la mesure et le calendrier sont explicités.

• Livrables de cadrage avant le développement.
• Corpus et critères de test versionnés.
• Jalons qui produisent une décision.
• Gestion écrite des changements.
• Visibilité sur coûts et consommation.
• Plan d’exploitation, incident et amélioration.

Associer les personnes qui connaissent les exceptions

Les utilisateurs du processus savent où les données manquent, quelles demandes se ressemblent et quelles erreurs sont coûteuses. Leur participation au cadrage et au pilote vise à améliorer les tests et à rendre les nouvelles responsabilités plus compréhensibles.

Former selon les rôles

Un administrateur, un superviseur et un utilisateur occasionnel n’ont pas le même besoin. La formation doit couvrir les gestes, les limites, les données interdites, le signalement d’une anomalie et la reprise manuelle, avec des supports réutilisables.

Mesurer l’adoption sans la confondre avec la valeur

Le taux d’utilisation montre qu’un outil est accessible, pas qu’il améliore le travail. Reliez l’adoption au temps net, à la qualité, aux corrections, aux escalades et aux retours des personnes concernées.

Cartographier les données et les fournisseurs

Identifiez quelles données entrent, où elles transitent, combien de temps elles restent, qui peut y accéder et si elles servent à améliorer un service tiers. La réponse doit couvrir aussi les journaux, sauvegardes, outils de support et sous-traitants.^[1][2][3][4]

Contrôler les identités et les actions

Comptes nominatifs, moindre privilège, séparation des environnements et validation des actions sensibles doivent être prévus dès l’architecture. Pour un agent, ajoutez limites d’outils, plafonds, détection des boucles et procédure d’arrêt.^[1][2][3][4]

Préparer les incidents et la sortie

Demandez comment une fuite, une réponse dangereuse, un coût anormal ou une régression sera détecté, contenu et documenté. La révocation des accès, la restitution des données et la reprise par un autre prestataire font partie du même exercice.^[1][2][3][4]

• Propriété et accès aux comptes.^[1][2][3][4]
• Lieux de traitement et support.^[1][2][3][4]
• Rétention, suppression et sauvegardes.^[1][2][3][4]
• Tests d’attaque et d’injection.^[1][2][3][4]
• Notification et gestion des incidents.^[1][2][3][4]
• Répartition contractuelle des responsabilités.^[1][2][3][4]

Questions sur l’expertise technique

Quel modèle ou quelle famille de méthodes envisagez-vous, pourquoi, et comment la qualité sera-t-elle testée ? Quelles compétences seront présentes au quotidien ? Comment traitez-vous les erreurs, versions et dépendances ?

Questions sur le besoin et la mesure

Comment reformulez-vous notre problème ? Quelle alternative plus simple comparez-vous ? Quelle référence faut-il relever, quel résultat principal suivrez-vous et quelles limites mettraient fin au pilote ?

Questions sur la méthode et les réalisations

Quels livrables terminent chaque phase ? Pouvez-vous montrer un plan de test, une documentation et un cas comparable en précisant votre rôle ? Comment gérez-vous une hypothèse invalidée ?

Questions sur l’éthique, la sécurité et les données

Quelles données sont nécessaires, quels fournisseurs interviennent, quels droits sont accordés et quelles actions exigent une validation ? Comment informez-vous les personnes et traitez-vous une contestation ou un incident ?

Questions sur le prix et le modèle économique

Quels coûts sont fixes, variables ou estimés ? Qui paie les modèles, connecteurs et environnements ? Qu’incluent maintenance, support, évolution et sortie ? Demandez des hypothèses de volume pour comparer le coût complet.

Promesses irréalistes et garanties excessives

Un ROI, une précision ou une date de récupération garantis avant l’accès aux données doivent alerter. Une estimation honnête expose ses hypothèses, ses marges d’incertitude et la décision prévue si le résultat n’est pas atteint.

Technologie opaque ou méthode floue

Le secret commercial ne justifie pas l’absence d’explication sur les flux, les fournisseurs, les tests et les responsabilités. Une accumulation de termes techniques sans livrables ni critères ne permet pas de vérifier la qualité du cadrage.

Références invérifiables et comptes captifs

Des témoignages sans contexte, des comptes créés au nom du prestataire et l’absence d’export augmentent la dépendance. Les accès structurants et les éléments nécessaires à la reprise doivent être contrôlés par le client.

Une solution agentique pour chaque problème

L’absence d’expérience RAG ou agentique peut être un défaut lorsque le besoin l’exige. À l’inverse, imposer un agent autonome à un processus stable est aussi un signal faible. La technique doit suivre le niveau de variabilité et de risque.

• Prix très précis sur un périmètre vague.
• Refus d’expliquer l’évaluation ou les limites.
• Aucun livrable intermédiaire ni transfert.
• Dépendance à une seule personne.
• Sécurité réduite à un logo de certification.
• Maintenance absente de l’offre.

Agence spécialisée ou généraliste

Une spécialiste peut apporter une profondeur utile sur une technologie ou un secteur. Une généraliste peut mieux coordonner produit, données, intégration et adoption. Le choix dépend de vos compétences internes et des interfaces entre disciplines.

Comprendre les écarts de tarifs

Comparez jours de travail, séniorité, livrables, environnements, licences, volumes, support et risques transférés. Une offre moins chère à la construction peut coûter davantage si elle exclut les tests, la documentation ou la maintenance.

Vérifier la compatibilité de travail

La qualité des échanges, la capacité à contredire une hypothèse et la transparence sur les difficultés sont des éléments à examiner. Organisez un atelier court avec les personnes qui interviendront réellement plutôt qu’un entretien uniquement commercial.

Une priorité stratégique ne justifie pas tous les projets

L’IA peut affecter expérience, opérations, recherche et produit, mais chaque cas doit encore démontrer un problème, une donnée, un responsable et une décision. L’agence doit aider à prioriser plutôt qu’à multiplier les démonstrations.^[1]

Le portefeuille compte plus qu’un cas isolé

Examinez dépendances communes, compétences internes, gouvernance et capacité de maintenance. Comparez le coût de plusieurs pilotes incompatibles à celui d’une fondation commune avant de choisir.^[1]

Conseil et gouvernance

À privilégier pour portefeuille, cadre de décision, risques et organisation, à condition que la sortie fournisse des priorités et livrables exploitables.

Développement et intégration

À privilégier quand architecture, API, données, sécurité et exploitation dominent. Vérifiez responsabilité produit et capacité à tester la valeur métier.

Spécialiste métier ou canal

Une spécialisation apporte des pratiques ciblées. Contrôlez toutefois les interfaces avec votre système d’information, vos données et les disciplines absentes de l’équipe.

Les limites doivent apparaître dans la proposition

Cherchez les situations où le système refuse, transfère, demande confirmation ou ne convient pas. Une agence crédible rend le risque et les inconnues visibles avant la vente.^[2][3][4]

Les preuves doivent survivre au discours commercial

Demandez registre de décisions, cartographie des données, tests, journaux, mentions utilisateur et procédure de recours adaptés au cas. Une charte générale ne prouve pas leur mise en œuvre.^[2][3][4]

Forfait, temps passé et abonnement

Le forfait exige un périmètre défini ; le temps passé rend les inconnues visibles ; l’abonnement couvre une capacité récurrente. Comparez qui porte le risque, quels plafonds existent et ce qui termine la mission.

Coût complet après livraison

Ajoutez modèles, infrastructure, outils, données, support, évaluations, mises à jour et temps interne. Une construction moins chère peut créer une exploitation plus coûteuse ou captive.

Faire un atelier avec l’équipe réelle

Observez écoute, reformulation, capacité à dire non, profondeur des questions et gestion d’un désaccord. Les personnes présentes à l’avant-vente ne doivent pas être les seules capables d’expliquer la solution.

Vérifier le rythme de décision

Alignez disponibilité métier, cadence des livrables, responsables d’arbitrage et délais de validation. Une bonne méthode échoue si aucune partie ne peut fournir les décisions attendues.

Ce qu’une agence peut apporter

Évaluez si l’accès coordonné à plusieurs compétences, l’expérience de cas comparables, une capacité temporaire et un regard critique raccourcissent réellement l’apprentissage du projet.

Ce qu’elle ne remplace pas

Finalité, responsabilité métier, connaissance des exceptions, propriété des données et acceptation du risque doivent rester portées par l’entreprise. La dépendance augmente si ce noyau n’est pas construit.