Consultant ou agence d'automatisation IA : comment choisir ?
Pour choisir un consultant ou une agence d'automatisation IA, demandez trois engagements écrits : un scope, c'est-à-dire un périmètre borné, une mesure avant et après, et l'ownership, la propriété claire du système et des données. Ajoutez un plan de sécurité, de maintenance et de transfert. Ces éléments séparent une démonstration séduisante d'un système exploitable.
La maîtrise d'un outil comme n8n, Make, Zapier ou d'un modèle précis ne suffit pas. Les plateformes changent. Le partenaire doit d'abord comprendre le métier, réduire le risque et construire une solution que l'entreprise peut mesurer, arrêter et reprendre.
Consultant, freelance, intégrateur ou agence : quelle différence ?
Le titre renseigne peu sur la qualité, mais il influence l'organisation.
- Un consultant IA peut cadrer le besoin, arbitrer les choix et piloter la réalisation. Vérifiez qui construit réellement et qui assure la maintenance.
- Un freelance en automatisation est souvent rapide et proche du terrain. Vérifiez la continuité de service, la documentation et le transfert.
- Un intégrateur connaît un écosystème ou un logiciel métier. Il est pertinent quand les contraintes d'intégration dominent le projet.
- Une agence d'automatisation IA apporte plusieurs compétences et davantage de capacité. Vérifiez que l'équipe présentée interviendra réellement et que le périmètre ne deviendra pas une facturation ouverte.
Le bon choix dépend du parcours, du risque et des outils, pas de la taille du logo.
Les 12 questions à poser avant de signer
Cette vérification préalable est une forme de due diligence : on contrôle les hypothèses, les risques, les preuves et les responsabilités avant l'engagement.
1. Quel problème précis allons-nous résoudre ?
La réponse doit nommer un parcours avec un début et une fin : « de la demande reçue au rendez-vous confirmé ». « Automatiser le service client » reste trop vague.
2. Pourquoi faut-il de l'IA ?
Un bon partenaire sait expliquer quelle étape nécessite un modèle et quelles étapes relèvent de règles ou de code. S'il utilise un LLM pour une opération qu'un filtre résout mieux, vous paierez plus pour une fiabilité inférieure.
3. Quelle est la baseline ?
Demandez le point de départ : délai, volume, taux d'erreur, demandes perdues, temps de traitement. Sans mesure initiale, le résultat final deviendra une opinion.
4. Quels sont les critères d'acceptation ?
Précisez les acceptance criteria, ou critères d'acceptation : résultats attendus, cas de test, taux d'erreur toléré, délais et comportements interdits. Une fonctionnalité « présente » n'est pas forcément utilisable.
5. Que fait le système quand il ne sait pas ?
La bonne réponse décrit une condition d'arrêt, une escalade et la personne qui reprend la main. Un agent qui répond à tout est un risque, pas une preuve de performance.
6. Quelles données sont utilisées ?
Demandez la finalité, le lieu d'hébergement, la durée de conservation, les sous-traitants, les journaux et les modalités de suppression. Un accès large « pour commencer » signale un cadrage incomplet.
7. Quelles permissions l'agent reçoit-il ?
Lecture, écriture, envoi, suppression et paiement n'ont pas le même risque. Le principe du moindre privilège consiste à donner seulement les droits nécessaires, pendant la durée nécessaire.
8. Comment le système est-il testé ?
Le partenaire doit parler de cas réels, d'exceptions, de tests de régression et d'evals. Changer un prompt ou un modèle peut améliorer un cas et en casser un autre. Un jeu de tests rend ce changement visible.
9. Comment saurons-nous qu'il fonctionne encore ?
Attendez des métriques, des alertes, des logs, une supervision et une procédure d'incident. Une automatisation en production doit signaler ses échecs.
10. Qui possède le système ?
Clarifiez les comptes cloud, le code, les workflows, les prompts, les données, le domaine et les clés API. Un système construit uniquement sur les comptes du prestataire crée une dépendance évitable.
11. Que coûte la deuxième année ?
Demandez l'hébergement, les modèles, les licences, la maintenance, le support et les évolutions. Si le support est critique, exigez un SLA, Service Level Agreement ou engagement de niveau de service, qui précise les horaires, délais de réponse et délais de rétablissement. Le devis de construction ne représente pas le coût total de possession.
12. Comment se passe la sortie ?
Le contrat doit prévoir un exit plan, ou plan de sortie : export, documentation, remise des accès, suppression des copies et possibilité de faire reprendre le système. Le handover, ou transfert opérationnel, doit permettre à une autre équipe d'exploiter la solution. La réversibilité se négocie avant le projet.
Quels signaux d'alerte doivent faire reculer ?
- Une promesse de chiffre d'affaires sans méthode d'attribution.
- Une solution imposée avant l'analyse du processus.
- Une démo limitée aux cas idéaux.
- Un devis en jours sans résultat ni plafond.
- Cinq chantiers lancés en parallèle pour un premier pilote.
- Aucun responsable humain dans le workflow.
- Un refus de documenter les limites ou les erreurs.
- Des références invérifiables ou des chiffres sans baseline.
- Un accès administrateur généralisé par défaut.
- Un support « illimité » sans délai ni périmètre de service.
Quelles preuves demander ?
Une preuve utile montre la méthode autant que le résultat. Demandez :
- un exemple de critères d'acceptation ;
- un plan de test anonymisé ;
- une architecture expliquant les flux de données ;
- un exemple de journal d'incident ;
- la façon dont un humain reprend la main ;
- ce qui a été mesuré avant et après sur un cas comparable.
Un projet personnel ou une démonstration technique peut prouver une capacité de construction. Il ne doit pas être présenté comme un résultat client. La distinction entre preuve, hypothèse et objectif protège les deux parties.
À quoi ressemble un engagement sain ?
Un cadre prudent suit quatre étapes : diagnostic, pilote, exploitation, extension. Le diagnostic se termine par un périmètre et un devis ferme. Le pilote traite un seul processus. L'exploitation mesure la fiabilité réelle. Le deuxième parcours vient après la preuve.
Le partenaire devrait aussi savoir refuser : une décision financière autonome, des données sans finalité, une promesse invérifiable ou un projet trop large. Dire non à une mauvaise automatisation fait partie du travail.
La grille de décision finale
Notez chaque candidat sur cinq dimensions : compréhension métier, qualité du cadrage, maîtrise du risque, propriété et réversibilité, preuve mesurable. La présentation commerciale et le nombre de technologies viennent ensuite.
Le jargon contractuel à retenir
- Scope : périmètre inclus dans la mission.
- Due diligence : vérification préalable des preuves, risques et hypothèses.
- Acceptance criteria : conditions objectives permettant d'accepter la livraison.
- Ownership : propriété des comptes, données, code et actifs livrés.
- SLA : engagement chiffré sur la qualité et les délais du service.
- Handover : transfert des accès, connaissances et procédures.
- Exit plan : organisation prévue pour arrêter ou transférer la solution.
- Vendor lock-in : dépendance excessive à un fournisseur.
Pour examiner une proposition, copiez dans le chat de ce site son périmètre, ses critères d'acceptation, ses coûts récurrents et ses règles de propriété. Les zones floues apparaissent généralement avant même de parler de technologie.
Par Anthony Dalin
Publié le