Comment choisir une agence IA

Une agence IA est adaptée lorsqu’une entreprise a identifié un processus à améliorer et qu’elle doit réunir plusieurs compétences pour passer à l’action : cadrage, données, développement, intégrations, expérience utilisateur, tests et déploiement. Elle apporte une équipe projet et une responsabilité de coordination que ne fournit pas toujours un consultant indépendant ou un logiciel standard.

Le recours à une agence devient particulièrement pertinent lorsque la solution doit s’insérer dans un environnement existant. Un agent qui consulte une base documentaire, une automatisation qui met à jour le CRM ou une application qui exploite des documents internes demandent des accès, des règles métier, des contrôles et une maintenance. Le devis doit couvrir ce chemin complet ou indiquer clairement où s’arrête l’intervention.

Un consultant convient mieux lorsqu’il faut d’abord arbitrer les priorités, établir une gouvernance ou préparer un cahier des charges indépendant. Un intégrateur devient central lorsque l’architecture, la sécurité et la connexion au système d’information dominent le projet. Un éditeur répond à un besoin couvert par un produit existant, avec un paramétrage limité et un coût récurrent lisible.

L’équipe interne est une option solide si elle possède le temps, les compétences et la responsabilité d’exploitation. Elle peut aussi travailler avec une agence sur une phase précise, puis reprendre le code et les opérations. Documentez l’arbitrage avant la consultation : ce choix détermine les profils à comparer et évite de demander le même résultat à des acteurs qui vendent des prestations différentes.

Décrivez le problème avec des faits observables : volume de demandes, temps passé, erreurs, retards, insatisfaction, risque documentaire ou dépendance à une personne. Précisez les utilisateurs, les étapes actuelles, les outils concernés et la décision que la solution doit faciliter. Cette description donne aux agences une base commune pour proposer un périmètre comparable.

Ajoutez les contraintes connues : données sensibles, hébergement, langues, disponibilité des équipes, période de test et budget indicatif. Séparez le résultat métier attendu des solutions imaginées. Une agence peut alors proposer une automatisation, un assistant, une recherche documentaire ou une évolution du processus sans être enfermée dans un outil choisi trop tôt.

La première réunion doit montrer comment l’agence explore les exceptions, les responsabilités et les conséquences d’une erreur. Une équipe qui comprend le métier reformule le flux, distingue les cas simples des cas sensibles et identifie les validations humaines nécessaires. Elle demande aussi ce qui arrive avant et après l’étape que vous souhaitez automatiser.

Comparez les comptes rendus ou notes de cadrage produits par les candidats. Vérifiez si les hypothèses sont explicites, si les zones d’incertitude sont listées et si les utilisateurs finaux ont une place dans la méthode. Une bonne compréhension se voit dans la précision du périmètre et des tests, pas dans la quantité de vocabulaire technique.

Demandez deux ou trois références proches du problème plutôt qu’une liste générale de clients. Pour chaque cas, l’agence doit pouvoir préciser le secteur, la taille de l’organisation, les données utilisées, les intégrations, la durée, le rôle exact de son équipe et la situation après livraison. Les éléments confidentiels peuvent être anonymisés.

Une référence publique peut être complétée par une démonstration, un livrable expurgé ou un échange privé autorisé avec un client. Demandez aussi un exemple de projet difficile ou interrompu. La manière dont l’agence explique les limites, les changements de périmètre et les apprentissages donne une information utile sur sa maturité.

Deux projets portant le même nom peuvent avoir des difficultés très différentes. Un chatbot alimenté par cinquante pages validées n’est pas comparable à un assistant qui doit respecter des droits fins sur plusieurs milliers de documents. Une automatisation sans API ne ressemble pas à un workflow construit sur des applications bien documentées.

Utilisez une grille de comparaison : volume, variété des données, niveau de qualité, nombre d’utilisateurs, criticité, intégrations, fréquence de mise à jour et responsabilité en cas d’erreur. Demandez quelles parties du résultat provenaient de l’agence, du client ou d’un logiciel tiers. Vous éviterez d’attribuer au prestataire une performance liée à un contexte beaucoup plus favorable.

Les compétences nécessaires dépendent du projet. Une application métier peut demander du développement logiciel, des API, des tests et de l’observabilité. Un RAG exige une stratégie documentaire, des droits d’accès, une méthode d’évaluation et un suivi des sources. Une automatisation demande une connaissance des connecteurs, des erreurs, des reprises et des limites de débit.

Demandez qui réalisera effectivement la mission, avec quel niveau d’expérience et quelle disponibilité. Faites expliquer les choix d’architecture avec leurs alternatives, coûts et dépendances. L’agence doit pouvoir décrire la gestion des secrets, les environnements de test, les logs, les sauvegardes, le déploiement et la procédure de retour arrière sans exposer d’informations sensibles.

Un POC doit répondre à une question de décision. Définissez le scénario, les données utilisées, les utilisateurs impliqués, la durée et le résultat attendu. Le périmètre doit être assez réduit pour apprendre vite, tout en restant représentatif des difficultés qui déterminent la suite : qualité documentaire, accès aux outils, performance, sécurité ou adoption.

Précisez ce qui sera réutilisable si le test réussit. Certains POC servent uniquement à valider une faisabilité et devront être reconstruits pour la production. D’autres peuvent constituer une première brique durable. Cette différence doit apparaître dans le devis, avec les hypothèses, les livrables et la décision prévue à la fin.

La recette traduit le besoin en observations vérifiables. Pour une extraction documentaire, mesurez les champs corrects, les omissions et les erreurs critiques. Pour un assistant, évaluez la pertinence, les citations, le respect des droits et la capacité à refuser une réponse. Pour une automatisation, contrôlez les cas normaux, les exceptions et la reprise après incident.

Constituez le jeu de test avant la démonstration finale et conservez une partie des cas hors de l’entraînement ou du paramétrage. Fixez les seuils, les personnes qui valident et les conséquences d’un échec. Les critères doivent refléter le risque métier ; une erreur rare mais grave peut peser davantage qu’un taux global satisfaisant.

La production ajoute des contraintes absentes d’une démonstration : comptes utilisateurs, droits, volumes, disponibilité, support, mises à jour, suivi des coûts et traitement des incidents. Demandez un plan de passage en production et les conditions nécessaires côté client. Le responsable d’exploitation doit être identifié avant la livraison.

Prévoyez une phase contrôlée avec un groupe d’utilisateurs, des indicateurs et une procédure de retour. La documentation doit couvrir l’architecture, les paramètres, les dépendances, les sauvegardes et les actions courantes. Si une agence s’appuie sur plusieurs services tiers, listez leurs contrats, régions d’hébergement et conditions de remplacement.

Cartographiez les données nécessaires, leur propriétaire, leur sensibilité, leur durée de conservation et les personnes autorisées. Donnez à l’agence les accès minimaux dans un environnement prévu pour le projet. Les comptes partagés et les exports manuels non suivis créent des risques difficiles à corriger plus tard.

Le contrat doit préciser les sous-traitants, les services de modèles, les zones d’hébergement et l’utilisation éventuelle des données pour améliorer un service tiers. Vérifiez les mécanismes de suppression, les journaux, la rotation des secrets et la fin des accès après la mission. Faites valider les exigences importantes par les responsables juridiques et sécurité concernés.

Identifiez ce que l’entreprise achète réellement : code source, licence, configuration, prompts, scénarios d’automatisation, jeux de test, documentation et droits sur les livrables. Les bibliothèques de l’agence et les composants tiers peuvent rester sous leurs licences propres, mais leur rôle doit être visible.

Créez les comptes structurants au nom du client lorsque cela est possible et organisez la remise des accès. Pour le no-code, vérifiez la propriété des espaces Make, n8n ou équivalents. Pour une application, demandez le dépôt, l’historique, les instructions de déploiement et la liste des secrets à recréer. Ces éléments déterminent la capacité à changer de prestataire.

Alignez les devis dans un tableau commun : cadrage, conception, préparation des données, développement, intégrations, tests, déploiement, formation, documentation, maintenance et licences. Notez les hypothèses, les exclusions et le temps demandé à vos équipes. Deux montants proches peuvent couvrir des responsabilités très différentes.

Repérez le mode de facturation, les jalons, les critères d’acceptation et la gestion des changements. Un forfait protège seulement si le périmètre est suffisamment clair. Une régie peut convenir à une phase exploratoire si le pilotage et les limites budgétaires sont organisés. Demandez une estimation des coûts récurrents séparée du coût initial.

Une solution IA évolue avec les données, les modèles, les APIs et les usages. Le contrat de maintenance doit distinguer correction, surveillance, évolution et assistance aux utilisateurs. Précisez les horaires, délais de réponse, niveaux de priorité et limites de volume. Demandez comment seront suivis la qualité, les coûts et les changements des services tiers.

Préparez la réversibilité dès la sélection : export des données, accès au code, documentation, transfert des comptes et période d’assistance. Une reprise réaliste dépend de la qualité des livrables et de la disponibilité des compétences. Évaluez son coût avant de vous engager sur une architecture difficile à remplacer.

Certains signaux demandent une clarification : promesse large sans données examinées, résultat garanti avant cadrage, références non contextualisées, dépendance forte à une seule personne, sécurité reportée à la fin ou absence de plan de maintenance. Un prix très bas peut aussi indiquer qu’une partie du travail reste chez le client.

Demandez une réponse écrite lorsque le discours commercial et le devis divergent. Vérifiez les sociétés contractantes, les sous-traitants et les profils affectés. Une agence sérieuse peut reconnaître une incertitude, proposer une étape de validation ou recommander de réduire le périmètre lorsque le projet n’est pas prêt.

La signature doit intervenir après l’alignement sur le besoin, les responsabilités, les preuves et les conditions d’exploitation. Utilisez cette liste lors de la revue finale avec le métier, l’IT, la sécurité, les achats et le sponsor du projet.