Agence d'automatisation IA ou consultant : que choisir ?

Choisissez un consultant lorsque le besoin principal est de diagnostiquer, prioriser ou concevoir la solution. Envisagez une agence lorsque la livraison exige réellement plusieurs disciplines coordonnées. Un développeur, une équipe interne ou un coach peut mieux convenir selon le périmètre. Décidez à partir des personnes nommées, des preuves d’acceptation, des limites de sécurité, de la responsabilité d’exploitation et du transfert, pas de l’étiquette.

Ce guide compare des modes d’engagement, pas des niveaux de qualité. Les intitulés se recouvrent : un consultant peut aussi développer, une agence peut mobiliser une seule personne et un freelance peut coordonner plusieurs spécialistes. Vérifiez donc le contrat, l’équipe nommée et les livrables plutôt que l’étiquette. Pour cadrer le processus en amont, commencez par choisir un workflow IA mesurable.

Commencer par la capacité que vous voulez acheter

Le choix devient plus simple lorsque l’acheteur sépare six questions. Les recommandations de la GSA pour l’achat d’IA proposent de partir du problème, des utilisateurs, des données, des risques et d’un pilote, plutôt que d’un outil déjà choisi. Ce standard de commande publique peut inspirer une entreprise privée à proportion de son contexte ; il ne constitue pas un avis juridique.

1. Capacité visée : faut-il diagnostiquer, concevoir, réaliser, former ou exploiter ?
2. Ambiguïté : le résultat et les critères d’acceptation sont-ils déjà définis ?
3. Périmètre borné : s’agit-il d’un seul workflow réversible ou d’un programme multi-systèmes ?
4. Disciplines nécessaires : faut-il réunir métier, données, intégration, sécurité, UX, conduite du changement et exploitation ?
5. Sensibilité stratégique : l’organisation doit-elle conserver elle-même la connaissance, le code, les comptes et l’architecture ?
6. Réversibilité : peut-on arrêter le pilote, revenir au processus manuel et changer de mainteneur sans perdre les actifs ?

Si ces réponses restent inconnues, achetez d’abord un cadrage court avec des livrables utilisables par un autre prestataire. Si elles sont stables et qu’un workflow borné est prêt à tester, demandez une proposition de réalisation assortie de tests d’acceptation. Le guide britannique d’achat de l’IA recommande notamment une approche pluridisciplinaire, des résultats définis, une gouvernance claire et une gestion du cycle de vie.

Consultant, agence, freelance, équipe interne ou coach

Les définitions suivantes sont des points de départ neutres. Elles ne préjugent ni des compétences d’une personne ni de la qualité d’une entreprise.

Une petite mission peut combiner ces modèles. Un consultant peut cadrer, un développeur réaliser et l’équipe interne accepter puis exploiter. Une agence peut assurer l’ensemble si ses rôles sont réellement mobilisés. Le point important est d’attribuer chaque responsabilité : décision métier, architecture, développement, sécurité, validation, déploiement, maintenance et conduite du changement.

Comparer le modèle réel, pas sa réputation

Préparer un brief minimum avant de consulter

La méthode de définition des exigences de la GSA insiste sur le besoin, les parties prenantes, les contraintes et les critères qui permettront d’évaluer les réponses. Pour un projet d’automatisation, le brief minimum devrait répondre aux questions suivantes.

Résultat, périmètre et preuve

• Quel résultat métier doit changer et quelle mesure actuelle sert de référence ?
• Quel déclencheur, quelles entrées, quelles sorties et quel système de référence sont concernés ?
• Quels cas sont inclus, exclus ou volontairement laissés au processus manuel ?
• Qui possède le processus et qui peut accepter ou refuser le résultat ?
• Quelle erreur est tolérable, laquelle impose une revue et laquelle arrête le système ?
• Quelles preuves seront produites pendant le pilote : jeux de tests, journaux, comparaison ou relecture ?

Systèmes, données et actions

• Quelles intégrations, API, exports, comptes et environnements existent ?
• Quelles données personnelles, confidentielles ou réglementées peuvent entrer dans le système ?
• Quels accès sont nécessaires, pour quelle durée et selon quel principe de moindre privilège ?
• Quelles actions sont seulement proposées, lesquelles écrivent dans un système et lesquelles exigent une approbation ?
• Quels modèles, hébergeurs, sous-traitants ou autres fournisseurs peuvent intervenir ?
• Les données ou interactions peuvent-elles être réutilisées pour entraîner ou améliorer un service ?

Propriété, exploitation et sortie

• Qui possède les comptes, dépôts, configurations, prompts, schémas, jeux de tests et autres artefacts ?
• Comment sont traités propriété intellectuelle, licences tierces et droits de modification ?
• Quels coûts sont fixes, variables, récurrents, dépendants du volume ou liés à la sortie ?
• Qui surveille, corrige, répond à un incident et approuve un changement après livraison ?
• Quel support, quelle maintenance et quels délais sont inclus ou proposés séparément ?
• Quel transfert permet à un successeur de reprendre le système sans dépendance cachée ?

Ce brief peut rester court, mais une réponse « à définir » doit être visible. Elle devient alors un poste de cadrage, pas une hypothèse silencieuse dans un forfait.

Utiliser des portes éliminatoires avant une grille de score

Un total élevé ne doit pas compenser une condition indispensable. Évaluez d’abord les portes pass/fail, puis comparez les offres restantes avec des preuves.

Portes pass/fail

Une proposition ne passe à l’étape suivante que si elle :

• accepte le périmètre, les exclusions, l’approbateur métier et les critères d’arrêt ;
• nomme l’équipe prévue, les sous-traitants connus et la responsabilité de livraison ;
• accepte les limites de données, d’accès, de réutilisation et de conservation ;
• décrit un test sur cas représentatifs, limites et échecs avant mise en service ;
• prévoit un retour manuel, une désactivation et une procédure d’incident ;
• restitue les actifs convenus et permet une passation exploitable ;
• rend visibles les coûts ponctuels, récurrents, variables et de changement.

Une porte n’est pas un verdict abstrait sur le prestataire. Elle traduit une exigence du projet. Une preuve manquante peut parfois être fournie pendant la consultation ; un refus explicite appelle une décision de risque.

Grille fondée sur des preuves

Attribuez à chaque critère une pondération avant de lire les offres, puis une note de 0 à 3 : 0 = absent, 1 = affirmation, 2 = preuve partielle, 3 = preuve directement vérifiable. Multipliez note et pondération, conservez le commentaire et faites noter indépendamment les critères sensibles par au moins deux personnes.

La grille produit une trace de décision, pas une précision mathématique. Réexaminez une pondération qui a été modifiée après lecture d’une offre. Le Data and AI Ethics Framework britannique apporte aussi des questions utiles sur la transparence, la responsabilité et les effets du projet.

Exiger des tests d’acceptation avant le déploiement

Un test d’acceptation relie une exigence à une preuve observable. Préparez-le avec le propriétaire métier et faites-le exécuter dans un environnement représentatif.

1. Cas représentatifs : échantillonner les volumes, langues, formats et situations ordinaires.
2. Cas limites et échecs : inclure données absentes, documents illisibles, indisponibilité d’API, doublons et dépassement de délai.
3. Sorties et tolérances : définir format, champs, source attendue, seuil d’écart et critères de refus.
4. Escalade et approbation : vérifier qu’une action sensible reste bloquée jusqu’à la décision autorisée.
5. Intégrité des intégrations : contrôler écritures, idempotence, rapprochement, horodatage et absence de corruption.
6. Moindre privilège : tester qu’un compte ne lit ni ne modifie ce qui est hors périmètre.
7. Injection et mésusage : tester des instructions hostiles, contenus non fiables, détournements d’outil et demandes interdites.
8. Conservation et suppression : vérifier durée, effacement, retour des données et traitement des sauvegardes convenu au contrat.
9. Journalisation : confirmer que décisions, versions, appels d’outil, erreurs et approbations nécessaires sont traçables sans journal excessif.
10. Latence, capacité et coût : tester charge normale, pic, files, limites, reprises et seuil de dépense.
11. Retour arrière : désactiver le système, rétablir le processus de secours et restaurer un état cohérent.
12. Documentation et passation : faire exécuter une opération et un incident simulé par la future équipe responsable.

Le NIST AI RMF Manage fournit un cadre volontaire pour prioriser les risques, documenter les réponses et suivre le système. Il ne s’agit ni d’une certification du fournisseur ni d’une garantie de conformité.

Fixer les frontières de données et d’accès

Une matrice simple évite que l’accès de démonstration devienne un accès de production permanent.

En France et dans l’Union européenne, un projet qui traite des données personnelles doit préciser les rôles, la finalité, la base applicable, la minimisation, les destinataires, les transferts, la conservation et les droits. La CNIL fournit des repères pour gérer la sous-traitance et des exemples de clauses. Vérifiez aussi la réutilisation des données ou interactions avec la FAQ de la CNIL sur l’IA générative.

Selon le système et le risque, il peut être nécessaire d’examiner la nécessité d’une AIPD avec le DPO ou le conseil compétent. Les clauses contractuelles types européennes pour l’IA sont conçues pour la commande publique et peuvent alimenter une discussion proportionnée ; elles ne constituent pas à elles seules un contrat privé complet. Pour la propriété intellectuelle et la maintenance par un successeur, le guide français des achats informatiques et de la propriété intellectuelle fournit un autre point de départ.

Préparer la passation et la sortie dès le contrat

Le paquet minimum de passation dépend du projet, mais il devrait préciser :

• architecture à jour, flux de données, inventaire des composants et décisions importantes ;
• dépôt de code et de configuration convenu, historique, instructions de construction et de déploiement ;
• prompts, schémas, contrats d’outils, jeux d’évaluation et résultats d’acceptation remis selon les droits négociés ;
• liste des comptes, secrets, propriétaires, procédures de rotation et dépendances tierces ;
• tableaux de bord, alertes, journaux, procédures d’incident, sauvegarde et retour arrière ;
• guide d’exploitation, calendrier de maintenance, limites connues et backlog accepté ;
• licences, droits d’usage, propriété intellectuelle et éléments non transférables clairement identifiés ;
• séance de passation, exercice de reprise par le client ou le successeur et période d’assistance définie.

Le processus de sortie nomme ensuite la date, le responsable, l’export, la révocation des accès, la rotation des secrets, le retour ou la destruction des données, la fermeture des ressources et la confirmation finale. Cette préparation réduit la dépendance sans supposer qu’une relation fournisseur doit se terminer.

Reconnaître les risques d’engagement sans caricaturer le fournisseur

Les signaux suivants justifient une question ou une condition supplémentaire. Ils ne prouvent pas qu’une catégorie de prestataire est mauvaise.

• une solution ou une plateforme est imposée avant la définition du résultat ;
• l’équipe présentée n’est pas celle qui réalisera effectivement la mission ;
• l’acceptation repose sur une démonstration choisie par le vendeur plutôt que sur des cas du client ;
• les exclusions, erreurs, actions sensibles et chemins de secours restent implicites ;
• des accès administrateur permanents sont demandés sans justification ni date de fin ;
• les sous-traitants, lieux de traitement, durées de conservation ou réutilisations restent inconnus ;
• les coûts d’usage, de support, de changement ou de sortie ne sont pas reliés à des hypothèses ;
• le code, les comptes, les tests ou la documentation ne sont pas accessibles au client selon l’accord prévu ;
• la maintenance dépend d’une seule personne sans documentation ni solution de continuité ;
• des promesses de résultat remplacent une méthode de mesure et des critères d’arrêt.

Où se situe JDTeachAI

JDTeachAI distingue trois besoins. Le coaching IA convient lorsque le décideur ou l’équipe veut apprendre à choisir, concevoir ou revoir un workflow. Les ateliers servent l’adoption collective et l’application à des cas internes. Les projets IA sur mesure concernent les acheteurs qui cherchent une réalisation bornée, avec cadrage, acceptation, données, exploitation et passation à préciser. La page automatisation IA présente le périmètre général.

Ce positionnement ne rend pas JDTeachAI adapté à chaque mission. Un programme qui exige une grande équipe permanente, une couverture sectorielle réglementaire spécifique ou un support international continu peut demander d’autres capacités ou un groupement. Le brief et les portes pass/fail doivent le révéler avant engagement.

Questions fréquentes d’un acheteur français

Une agence d’automatisation IA est-elle plus sûre qu’un consultant ?

Pas par nature. La sécurité dépend de l’architecture, des accès, des pratiques, des personnes mobilisées, des tests et de l’exploitation. Une agence peut apporter plusieurs spécialistes ; un consultant peut offrir une responsabilité directe. Demandez les mêmes preuves au modèle réellement proposé.

Comment comparer deux offres dont le périmètre diffère ?

Faites répondre les candidats au même brief, aux mêmes portes éliminatoires et au même scénario de test. Isolez les options, hypothèses et exclusions. Si une offre inclut cadrage ou maintenance et l’autre non, comparez les livrables et le coût total du scénario, pas seulement le total initial.

Quelles questions RGPD poser au prestataire ?

Clarifiez rôles, finalité, base applicable, données nécessaires, sous-traitants, localisation, transferts, conservation, réutilisation, droits, sécurité, incident, retour et destruction. Examinez l’AIPD si elle est applicable avec votre DPO ou conseil. Ce guide prépare la discussion sans fournir d’avis juridique.

Faut-il céder tous les droits de propriété intellectuelle ?

Pas nécessairement. Il faut surtout identifier les éléments préexistants, spécifiques, tiers et générés pendant la mission, puis négocier les droits nécessaires pour utiliser, modifier, maintenir et faire reprendre le système. Les comptes, données, configurations et artefacts critiques doivent suivre le modèle d’exploitation choisi.

Quand choisir une équipe interne ou du coaching ?

Préférez une capacité interne lorsque le workflow est stratégique, évolue souvent et justifie une responsabilité durable dans l’organisation. Le coaching aide cette équipe à structurer sa méthode ou revoir ses choix. La réalisation externe reste utile pour un besoin borné ou une compétence ponctuelle, à condition d’organiser le transfert.

Pour préparer une consultation, rassemblez le résultat, le processus actuel, les données, les actions, les critères d’acceptation et la passation attendue. Comparez ensuite l’engagement réel. Vous pouvez compléter ce travail avec les 12 exemples d’automatisation et leur méthode de ROI.