Comment choisir une agence pour développer l’intelligence artificielle dans votre entreprise ?

Choisir une agence d’intelligence artificielle demande de vérifier comment elle transforme un besoin métier en service utilisable, contrôlable et transmissible. Une démonstration montre un fonctionnement possible. Pour décider, demandez aussi les conditions de réussite, les résultats d’évaluation, les limites et les responsabilités après livraison. La proposition doit vous permettre de comprendre ce qui sera accepté, corrigé ou abandonné.

Anaska, propose ici une méthode de consultation. Les contrôles, modèles et conditions de validation qui suivent sont des recommandations de la rédaction, à adapter à votre usage. Vous pouvez les employer pour préparer un dossier, interroger les prestataires puis examiner leurs réponses avec les personnes qui utiliseront et exploiteront la solution.

Qualifier le problème et décider si l’IA est pertinente

Commencez par décrire une situation de travail observable. Qui réalise la tâche ? Quelles informations utilise cette personne ? Quel résultat attend-elle ? Où rencontre-t-elle une difficulté ? Faites décrire le parcours actuel, y compris les vérifications, les exceptions et les reprises manuelles. Cette description servira de référence lorsque l’agence proposera une nouvelle organisation.

Exemple pédagogique : une équipe cherche des instructions dans une documentation interne. Le besoin consiste à retrouver un passage applicable, afficher sa provenance et signaler les documents contradictoires. Un assistant conversationnel constitue une réponse possible ; une recherche mieux organisée mérite également un examen. Demandez à l’agence ce qui justifie chaque option et dans quelles circonstances elle conseillerait de renoncer à l’IA.

Les recommandations britanniques sur l’achat d’IA visent principalement les administrations centrales et concernent surtout l’apprentissage automatique. Elles proposent notamment de partir du problème et d’examiner des alternatives. Nous reprenons ce repère méthodologique dans un contexte d’entreprise, sans en déduire d’obligation juridique.

Livrable recommandé : une fiche décrivant l’utilisateur, la tâche, le résultat attendu, les exclusions et la solution actuelle. Validez-la avec le responsable métier. Évitez une formulation qui impose déjà une technologie : elle empêcherait de comparer des réponses différentes au même problème.

Vérifier les données et les conditions d’accès

Demandez un examen des informations nécessaires au cas d’usage retenu. Préparez un inventaire indiquant leur emplacement, leur format, leur responsable interne et leur fréquence de modification. Distinguez les données disponibles des contenus simplement envisagés. Une proposition qui suppose un historique complet doit identifier cette hypothèse avant que vous acceptiez son périmètre.

Notre recommandation consiste à faire examiner un échantillon représentatif dans des conditions de partage définies. Demandez une liste des défauts constatés : documents contradictoires, champs manquants, versions anciennes, doublons ou catégories absentes. Faites expliquer leurs conséquences sur l’usage, puis attribuez chaque correction à votre équipe ou à l’agence. Évitez une mention générale de nettoyage sans résultat attendu.

Le diagnostic devrait aussi décrire les accès proposés : personnes autorisées, environnements utilisés, composants destinataires et conservation prévue. Demandez à l’agence de distinguer ce qu’elle maîtrise directement des paramètres dépendant d’un service tiers. Une réponse inconnue appelle une vérification identifiée, avec un responsable.

Condition de validation : le responsable des données confirme que l’échantillon représente suffisamment le périmètre envisagé. Si certaines populations ou situations manquent, réduisez explicitement le pilote. Ne transformez pas l’absence de données en présomption de faisabilité : consignez ce qui demeure impossible à évaluer.

Examiner l’équipe à travers ses décisions techniques

Demandez qui conduira les entretiens métier, préparera les données, développera la solution, réalisera l’intégration et assurera le suivi. Une même personne peut couvrir plusieurs fonctions ; vérifiez surtout leur couverture effective et la disponibilité annoncée. Faites préciser les interventions de partenaires et la personne qui arbitrera les désaccords techniques.

Pour examiner une expérience présentée par l’agence, demandez le problème traité, sa contribution exacte, les contraintes rencontrées et les preuves produites. Une présentation anonymisée peut éclairer la démarche si elle distingue les observations des conclusions. Ne considérez pas une capture d’écran ou une liste de technologies comme une explication suffisante du travail réalisé.

Exercice pédagogique recommandé : soumettez une ambiguïté de votre brief et demandez comment l’équipe la résoudrait. Observez les questions posées, les hypothèses explicitées et les vérifications proposées. Cet échange permet d’apprécier la façon de travailler sans demander gratuitement une solution complète ni exposer des informations inutiles à la consultation.

Attendez une proposition d’organisation indiquant les interlocuteurs, les décisions attendues de votre entreprise et les modalités de remplacement. Validez également votre propre capacité à participer. Si aucun utilisateur ne peut examiner les résultats, prévoyez cette disponibilité avant le pilote : l’agence ne peut pas décider seule de ce qui convient au métier.

Construire un protocole d’évaluation avant le pilote

Demandez un protocole écrit avant de développer le prototype. Il doit décrire les situations évaluées, les réponses attendues, la méthode de jugement et la façon de consigner les désaccords. Séparez les exemples utilisés pour ajuster la solution des cas réservés à son évaluation. Demandez comment cette séparation sera maintenue au fil des corrections.

Constituez les cas avec les utilisateurs : demandes courantes, formulations ambiguës, données incomplètes et situations hors périmètre. Pour chaque catégorie, déterminez le comportement acceptable. Une réponse pertinente, une abstention et une demande de précision peuvent correspondre à des issues différentes, toutes utiles selon la situation. Évitez un indicateur global qui masquerait les erreurs les plus gênantes.

Prévoyez aussi une comparaison avec le fonctionnement actuel. L’agence devra expliquer ce que la solution change pour l’utilisateur, y compris la vérification et les reprises. Convenez des seuils avec les personnes responsables de l’usage, sans reprendre automatiquement ceux d’une démonstration extérieure.

Condition de validation : chaque critère possède une définition compréhensible, une méthode de mesure et un décideur. Faites joindre les résultats détaillés au bilan. Si un critère échoue, le rapport doit permettre de choisir entre correction, réduction du périmètre et arrêt, plutôt que conclure simplement à un pilote prometteur.

Comparer les preuves à chaque phase du projet

La preuve attendue doit évoluer avec la décision à prendre. Au cadrage, cherchez une compréhension partagée. Pendant le pilote, demandez des résultats reproductibles. Avant l’ouverture du service, vérifiez son fonctionnement dans votre environnement. La rédaction recommande de préparer cette progression dès la consultation pour éviter qu’une démonstration initiale serve de justification à toutes les étapes.

Pour chaque preuve, demandez sa date, son périmètre et les versions concernées. Un résultat ancien peut rester instructif, mais sa portée doit être expliquée. Consignez aussi les réserves acceptées : leur présence ne rend pas automatiquement une proposition inutilisable, à condition que leurs conséquences soient comprises et suivies.

Définir les limites et rendre l’intervention humaine praticable

Demandez une description des usages autorisés, des usages exclus et des situations où le système doit s’arrêter ou solliciter une personne. Pour un assistant documentaire, précisez notamment le traitement des sources absentes ou contradictoires. Faites montrer ces comportements sur des cas préparés. Une affirmation générale sur la fiabilité ne remplace pas cette observation.

Organisez ensuite la vérification humaine. Qui examine le résultat ? Avec quelles informations ? Peut-on corriger, refuser et reprendre le travail autrement ? Notre recommandation est de demander une démonstration du parcours complet, depuis la proposition automatique jusqu’à la décision finale. Une validation systématique sans éléments de contrôle laisse son utilité à démontrer.

Exemple pédagogique : un outil propose une catégorie pour une demande entrante. L’utilisateur devrait pouvoir consulter les éléments ayant motivé la proposition, sélectionner une autre catégorie et signaler une ambiguïté. Le protocole vérifiera aussi que cette correction atteint bien le système destinataire, sans être écrasée ensuite.

Le livrable attendu comprend les règles d’escalade, les rôles et le mode de secours. Validez-le avec les utilisateurs concernés en observant leur capacité à traiter une erreur. Évitez de confondre présence d’un bouton de confirmation et supervision effective : examinez la compréhension, la possibilité d’action et la charge de vérification.

Établir une gouvernance fondée sur des arbitrages explicites

Le cadre AI RMF du NIST, publié le 26 janvier 2023, est destiné à un usage volontaire. Il vise à intégrer les considérations de confiance à la conception, au développement, à l’utilisation et à l’évaluation des systèmes d’IA. Ce repère peut structurer vos échanges ; sa mention seule ne démontre pas la qualité d’une réalisation.

Notre recommandation est de demander un registre adapté au projet. Chaque risque identifié devrait être relié à un scénario, une conséquence, un contrôle et une personne responsable. Distinguez les risques traités, les risques acceptés et les questions ouvertes. Demandez quelle preuve permettra de considérer un contrôle comme opérationnel.

Définissez les décisions réservées à votre entreprise : changement d’usage, extension des données, ouverture à d’autres utilisateurs ou suspension du service. Faites préciser ce que l’agence peut modifier dans son intervention courante et ce qui demande une validation. Évitez une gouvernance réduite à des réunions sans décision enregistrée.

Condition de validation : choisissez un scénario d’erreur et retracez son traitement avec les interlocuteurs. Le responsable doit pouvoir retrouver le signalement, comprendre l’arbitrage et vérifier l’action décidée. Si plusieurs personnes pensent qu’une autre équipe est responsable, clarifiez cette répartition avant la mise en service.

Vérifier l’intégration dans les parcours existants

Demandez un schéma des échanges entre la solution, vos outils et les services tiers proposés. Pour chaque connexion, faites indiquer les informations lues ou écrites, les droits utilisés et le comportement en cas d’échec. Les caractéristiques d’un composant doivent être documentées pour sa configuration précise, sans les attribuer automatiquement à toute solution d’IA.

Faites couvrir les parcours qui dépassent la production d’une réponse : authentification, changement de rôle, validation, enregistrement et reprise après interruption. Si le système propose une action dans un outil métier, vérifiez quand cette action devient effective et comment l’utilisateur en reçoit confirmation. Évitez les traitements dont l’issue reste invisible.

Exemple pédagogique : après validation d’une proposition, une connexion échoue. Le parcours attendu peut conserver la demande en attente et proposer une reprise contrôlée. Demandez comment l’agence vérifiera qu’une nouvelle tentative ne crée pas un enregistrement en double. Le comportement exact reste à décider selon votre processus.

Le dossier d’intégration devrait contenir les interfaces, les dépendances et les résultats d’essais. Faites examiner ce dossier par les personnes qui administrent vos outils. Validez l’intégration lorsque les parcours normaux et les incidents retenus ont été observés dans un environnement représentatif, avec les restrictions restantes explicitement décrites.

Lire le devis comme un ensemble de livrables vérifiables

Pour comparer les propositions, transmettez une même trame de réponse. Demandez ce qui est inclus, ce qui dépend de votre équipe et ce qui reste optionnel. Distinguez les travaux initiaux des prestations récurrentes. L’objectif éditorial est de rendre visible la couverture du projet, sans confondre une proposition de prototype avec un service exploitable.

Demandez comment une hypothèse invalidée sera traitée : nouveau périmètre, travail complémentaire ou abandon d’une fonction. Faites également préciser ce qui constitue une correction et ce qui relève d’une évolution. Avant votre choix, reprenez les exclusions avec chaque interlocuteur ; une différence de couverture peut expliquer des propositions apparemment comparables.

Préparer l’exploitation et la réévaluation

Avant l’ouverture, demandez qui reçoit les incidents, qui les qualifie et qui décide d’une restriction d’usage. Décrivez les informations utiles au diagnostic tout en faisant examiner les accès et la conservation proposés. Une trace technique doit avoir un objectif explicite ; demandez quels éléments l’équipe pourra réellement consulter pour comprendre une erreur.

Préparez une procédure distinguant panne, résultat incorrect et changement du besoin métier. Ces situations peuvent demander des réponses différentes. Pour chaque intervention, faites préciser comment la correction sera vérifiée et comment les utilisateurs seront informés. Évitez une maintenance définie uniquement par la disponibilité du service lorsque votre attente comprend aussi la qualité des résultats.

Notre recommandation consiste à identifier les changements qui déclenchent une réévaluation : nouvelle documentation, modification des instructions, remplacement d’un composant ou extension du public utilisateur. Demandez comment conserver une version de référence et comparer les comportements avant et après modification. Le protocole initial doit rester exploitable, avec ses limites.

Condition de validation : faites parcourir un incident fictif aux équipes chargées du suivi. Elles doivent savoir le signaler, retrouver les informations pertinentes et décider d’une reprise. Complétez la formation par des situations d’erreur et d’abstention ; une présentation des fonctions seules ne prépare pas suffisamment ces décisions.

Organiser la réversibilité et arrêter le choix final

Demandez un inventaire des éléments récupérables : données, configurations, instructions, code spécifique, documentation et cas d’évaluation. Faites distinguer les éléments transmissibles des services tiers dont l’usage repose sur un accès séparé. Un export de données ne prouve pas à lui seul que le fonctionnement pourra être repris ailleurs.

La rédaction recommande un essai de transmission adapté au périmètre. Une personne qui n’a pas développé la solution devrait pouvoir suivre la documentation, retrouver les paramètres et exécuter les contrôles prévus. Identifiez les étapes encore dépendantes de l’agence, puis demandez leur explication. Précisez également comment les accès seront remplacés ou désactivés lors du départ.

Pour décider, rassemblez les preuves obtenues et les questions ouvertes. Examinez les points décisifs séparément : faisabilité des données, qualité évaluée, intervention humaine, intégration, exploitation et reprise. Une faiblesse majeure sur un usage indispensable mérite un arbitrage explicite, même si d’autres aspects de la proposition sont convaincants.

Consignez enfin les engagements retenus, les exclusions et les réserves avec leurs responsables. Appuyez votre choix sur ce dossier commun. Une agence adaptée à votre projet doit pouvoir expliquer ses décisions, montrer les vérifications convenues et transmettre les éléments nécessaires à la suite du travail, dans le périmètre que vous aurez validé.