Quels livrables attendre d’un consultant IA ?

Commencez par distinguer conseil, expérimentation et déploiement

Le mot « accompagnement » peut recouvrir des prestations très différentes. Un consultant chargé d’identifier vos priorités n’est pas nécessairement engagé pour développer votre futur logiciel.

Si votre attente porte sur une application utilisée quotidiennement, vérifiez que le prestataire intervient comme partenaire opérationnel capable de coder et de déployer, et pas uniquement comme conseiller. Cette distinction évite de découvrir en fin de mission qu’un nouveau budget sera nécessaire pour passer à l’exécution.

Les livrables d’un consultant ai, du diagnostic au suivi

Les sept éléments suivants constituent une grille de discussion. Ils ne sont pas tous nécessaires pour chaque mission : retenez ceux qui correspondent au périmètre acheté et faites préciser leurs conditions de réception.

1. Un diagnostic métier fondé sur le travail réel

Le diagnostic doit décrire un processus identifiable : qui reçoit la demande, quelles informations sont consultées, quelles décisions sont prises et où apparaissent les ressaisies. Une présentation générale sur les possibilités de l’intelligence artificielle ne suffit pas.

Attendez une cartographie du fonctionnement actuel, les irritants constatés et une première mesure de référence. Selon le sujet, cette mesure peut porter sur le temps de traitement, le nombre de dossiers en attente ou la fréquence des erreurs.

Le document doit également distinguer les problèmes qui nécessitent de l’IA de ceux qu’une règle métier, une meilleure organisation ou une connexion entre logiciels peut résoudre.

Critère de réception : un responsable métier doit pouvoir reconnaître son fonctionnement dans le diagnostic, corriger les éventuels écarts et comprendre pourquoi le cas d’usage proposé mérite d’être étudié. Les sources utilisées doivent être identifiables : entretiens, échantillons de dossiers ou observations du processus. Sans cette traçabilité, les conclusions restent difficiles à vérifier.

2. Une feuille de route avec des hypothèses économiques explicites

La feuille de route du consultant ai doit transformer le diagnostic en décisions : quel chantier lancer, lequel différer et lequel abandonner. Une liste de vingt idées sans ordre de priorité reporte simplement le travail d’arbitrage sur votre équipe.

Chaque cas d’usage retenu mérite une fiche courte indiquant le problème, les utilisateurs concernés, les données nécessaires, les dépendances techniques et le résultat attendu. Ajoutez un responsable côté entreprise et un point de décision avant d’engager l’étape suivante.

L’estimation économique doit séparer le coût de réalisation des dépenses récurrentes : hébergement, licences, appels aux modèles, maintenance et temps de supervision. Les gains prévisionnels doivent conserver leurs hypothèses visibles, notamment le volume traité et le taux d’adoption envisagé.

Un gain de temps n’est pas automatiquement une économie de trésorerie. Il peut surtout libérer de la capacité pour traiter davantage de dossiers ou améliorer le service.

Critère de réception : vous pouvez choisir un premier chantier et expliquer ce choix à votre direction, sans dépendre d’une promesse de retour sur investissement impossible à reconstituer.

3. Un dossier données, sécurité et conformité adapté à l’usage

Demandez au consultant ai de documenter quelles données entrent dans le système, où elles circulent et qui peut y accéder. Un schéma simple des flux est souvent plus exploitable qu’une longue annexe technique déconnectée du projet.

Le dossier doit identifier les fournisseurs impliqués, les durées de conservation prévues, la gestion des accès et les conditions d’utilisation des données par les services tiers. Il doit aussi préciser les informations exclues du traitement et les procédures prévues en cas d’incident.

Lorsque des données personnelles sont traitées, le cadrage doit traiter les responsabilités au titre du RGPD, la base légale, l’information des personnes et les contrats de sous-traitance nécessaires. Une analyse d’impact peut être requise si le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés.

Le règlement européen sur l’intelligence artificielle impose également d’examiner le rôle de l’entreprise et la qualification du système pour déterminer les obligations applicables et leur calendrier. Un hébergement européen ne règle pas, à lui seul, toutes ces questions.

Critère de réception : les risques, les mesures prévues et les points nécessitant une validation juridique sont explicitement distingués. Une affirmation générale de « conformité totale » ne remplace pas cette analyse.

4. Un prototype accompagné de preuves de test

Un prototype sert à vérifier une hypothèse, pas à donner l’illusion d’un produit terminé. Son dossier doit préciser ce qui fonctionne, ce qui est simulé et ce qui reste manuel.

Prenons un catalogue de spectacles, animations et ateliers comme celui d’Entertainmens. Pour une agence de ce secteur, un scénario hypothétique serait de préparer une sélection d’animations à partir d’un brief client. Cet exemple ne décrit pas une mission réalisée pour cette entreprise.

Le test devrait vérifier si la sélection respecte les contraintes renseignées, si elle s’appuie sur le catalogue et si elle signale les informations manquantes plutôt que d’inventer une disponibilité ou un prix. Le consultant ai doit restituer les résultats sur ces situations, pas seulement montrer une réponse réussie.

Exigez un jeu de tests représentatif, avec des demandes simples, des demandes ambiguës et des cas à refuser. Pour chaque test, conservez le résultat attendu, la réponse obtenue et la décision de validation.

Critère de réception : votre équipe peut reproduire les essais, constater les limites et décider si une mise en production est justifiée. Une démonstration préparée à l’avance ne remplit pas cette fonction.

5. Un outil déployé avec un procès-verbal de recette

Si le contrat inclut la mise en production, la livraison du consultant ai doit couvrir les connexions réelles, les droits des utilisateurs et les comportements en cas d’échec. Une interface accessible ne prouve pas que le processus fonctionne de bout en bout.

La recette consiste à vérifier les exigences convenues dans l’environnement prévu. Elle doit inclure les cas ordinaires et les exceptions : donnée absente, doublon, indisponibilité d’un service ou tentative d’accès non autorisée.

Pour un agent autorisé à agir, distinguez les opérations autonomes de celles qui nécessitent une confirmation. Envoyer un brouillon à un collaborateur et transmettre une offre à un client n’engagent pas le même niveau de responsabilité.

Critère de réception : les tests sont consignés, les anomalies restantes sont classées et leur traitement est décidé avant la signature de la recette. Le dispositif de retour arrière ou de fonctionnement dégradé est également expliqué.

6. Une documentation et un transfert qui rendent l’équipe autonome

La documentation doit servir à quelqu’un d’autre que son auteur. Prévoyez un guide utilisateur pour les tâches courantes et un dossier technique pour l’administration, le dépannage et les évolutions.

Le guide métier explique comment traiter les exceptions, corriger une donnée et demander de l’aide. Le dossier technique décrit l’architecture, les connexions, les configurations, les versions et les procédures de déploiement. Pour une solution générative, il doit aussi couvrir les instructions et les sources documentaires nécessaires à son fonctionnement.

À ce stade, le consultant ai doit organiser la remise des accès selon les règles de sécurité convenues. Les comptes, dépôts et ressources nécessaires à l’exploitation doivent être identifiés, sans mots de passe dispersés dans un document partagé.

La formation complète ce transfert. Faites travailler un utilisateur sur un cas réel, sans que le prestataire réalise les manipulations à sa place. Vous pouvez adapter ce volet en choisissant une formation IA centrée sur les usages de vos équipes métier.

Critère de réception : un utilisateur sait accomplir sa tâche et un administrateur sait où intervenir. Le contrat précise les droits sur les développements spécifiques, ainsi que les licences et dépendances tierces qui subsistent.

7. Un bilan de résultats après utilisation réelle

Le bilan remis par le consultant ai doit comparer une situation de départ et une situation observée sur un périmètre comparable. Mesurer uniquement le nombre de réponses générées ou de comptes créés ne démontre pas un bénéfice opérationnel.

Retenez quelques indicateurs adaptés au processus : temps complet par dossier, taux de correction, délai de réponse, coût d’exploitation et usage effectif par les personnes concernées. Le temps complet inclut la vérification humaine et le traitement des erreurs.

Exemple de calcul, sans promesse de résultat : pour 100 dossiers mensuels, passer de dix à quatre minutes par dossier, vérification comprise, représente dix heures libérées par mois. Ce résultat doit ensuite être rapproché des coûts récurrents et de l’usage réellement fait de cette capacité.

Demandez aussi une analyse des échecs. Si l’outil est peu utilisé, faut-il modifier le parcours, améliorer les données ou revoir le cas d’usage ? Le livrable doit déboucher sur une décision : poursuivre, corriger, élargir ou arrêter.

Critère de réception : la méthode de mesure, la période observée et les limites de comparaison sont visibles. Le suivi après déploiement doit être prévu au contrat, car il n’est pas automatiquement inclus dans une mission de construction.

Faites inscrire la réception dans le devis

Un livrable bien nommé reste insuffisant si personne ne sait comment l’accepter. Le devis d’un consultant ai doit relier chaque remise à une règle de validation compréhensible par votre entreprise.

Pour chaque élément contractuel, faites préciser :

• Le contenu et le format : document modifiable, dépôt de code, environnement accessible ou session de transfert.
• Le responsable de validation : la personne métier ou technique habilitée à accepter le livrable.
• Les preuves attendues : résultats de tests, démonstration reproductible ou exercice réalisé par un utilisateur.
• Le traitement des écarts : délai de correction, classement des anomalies et conditions d’une nouvelle vérification.
• Les limites de prestation : maintenance, assistance, consommations tierces et évolutions incluses ou exclues.

Évitez les formulations comme « automatisation complète » ou « solution clé en main » sans définition opérationnelle. Préférez une description observable : la demande est enregistrée, les champs obligatoires sont contrôlés, un brouillon est préparé puis soumis à validation.

Le contrat doit également distinguer une correction d’anomalie d’une nouvelle demande fonctionnelle. Sans cette distinction, chaque ajustement risque de devenir une discussion commerciale.

Enfin, associez les personnes qui utiliseront l’outil à la réception. Une validation purement technique peut laisser passer un parcours impraticable au quotidien, même lorsque toutes les connexions fonctionnent.

Questions fréquentes

Cadrer un projet qui laisse un outil réellement exploitable

Le bon dossier de livraison ne se mesure pas au nombre de pages. Il permet de vérifier le résultat, de comprendre les limites et de reprendre la main sur l’exploitation.