Exigences envers un consultant

Ce que recouvrent réellement les exigences envers un consultant

Lorsqu'une équipe métier commence à évaluer un projet d'IA ou d'automatisation, les « exigences envers un consultant » recouvrent en réalité deux choses différentes à la fois : ce dont le consultant a besoin de vous pour bien faire son travail, et ce que vous devez exiger de lui avant de le laisser approcher vos systèmes et vos données. Les deux comptent, et les confondre est une source fréquente de déception.

Cet article se concentre surtout sur le second sens, car c'est là que les dirigeants ont le plus de marge de manœuvre et le moins d'expérience. Un consultant incapable d'exprimer clairement ses propres exigences, ou qui accepte un brief vague sans le questionner, envoie lui-même un signal à ne pas ignorer.

Commencez par un objectif métier explicite, pas par une liste de souhaits technologiques

Une erreur fréquente consiste à cadrer un projet autour d'un outil (« nous voulons un chatbot », « nous voulons automatiser les emails ») plutôt qu'autour d'un résultat dont l'entreprise a réellement besoin. Un consultant digne de ce nom doit questionner un brief vague et demander quel changement mesurable le projet doit produire, pour qui, et d'ici quand.

Ce n'est pas une simple formalité. Sans objectif explicite, impossible de juger ensuite si le projet a réussi, et le périmètre a tendance à dériver à mesure que chaque partie prenante projette ses propres attentes sur une initiative mal définie. Exiger que le consultant couche l'objectif par écrit, en termes métier simples, avant tout début de conception technique, est une vérification raisonnable et peu coûteuse.

• Demandez l'objectif en une phrase, formulée en termes métier, pas techniques
• Demandez ce qui constituerait un échec, pas seulement une réussite
• Vérifiez que l'objectif est porté par une personne ayant l'autorité de changer les méthodes de travail, pas seulement par un sponsor IT

Exigences en matière d'accès et de contrôle des données

Tout projet d'IA ou d'automatisation touche aux données, et la qualité et les limites de ces données déterminent en grande partie ce qui est réalisable. Un consultant sérieux demandera dès le départ quelles données existent, où elles se trouvent, qui en est propriétaire et quelles contraintes s'y appliquent, plutôt que de supposer que l'accès sera simplement accordé une fois le projet lancé.

Les dirigeants doivent aussi exiger la même rigueur dans l'autre sens : une description écrite des données dont le consultant a besoin, pourquoi, pour combien de temps, et sous quels contrôles d'accès. Une demande vague d'« accès complet » aux systèmes doit susciter des questions. Un accès maîtrisé et délimité, aligné sur l'objectif précis, constitue une exigence de base raisonnable, et le consultant doit pouvoir justifier toute exception.

Les problèmes de qualité des données découverts en cours de projet coûtent bien plus cher à corriger que ceux détectés lors du cadrage. Demander au consultant comment il compte évaluer la qualité des données avant de s'engager sur un délai de livraison est une exigence juste et utile.

Revue humaine et garde-fous adaptés

Comme les résultats d'un projet d'IA ou d'automatisation dépendent fortement du contexte et de la qualité de ce qui l'alimente, aucun consultant responsable ne devrait présenter un système comme quelque chose à déployer puis à ignorer. Une exigence sur laquelle insister est une étape de revue humaine définie pour toute production qui affecte les clients, l'argent, la conformité ou la sécurité, au moins tant que le comportement du système n'est pas bien compris en production.

Les garde-fous doivent être proportionnés au risque plutôt qu'uniformes. Une automatisation interne à faible enjeu peut nécessiter une revue plus légère qu'un processus visible des clients. Demandez au consultant de proposer où se situe la revue humaine dans le workflow et pourquoi, plutôt que d'accepter une assurance générale du type « le système est sûr ».

C'est aussi là que la gouvernance rejoint la pratique : des garde-fous qui rendent le système inutilisable vont à l'encontre du but recherché. La bonne exigence est donc un processus de revue dimensionné au risque réel, et non un dispositif maximal appliqué partout.

Une mesure après le déploiement, pas seulement à la livraison

Un projet évalué uniquement au moment de la livraison, à partir d'une démo ou d'un jeu de données de test, en dit peu sur ses performances une fois de vrais utilisateurs et de vraies données impliqués. Une exigence raisonnable est que le consultant définisse à l'avance ce qui sera mesuré en production et sur quelle période, et qu'il reste impliqué, ou transmette une méthode claire, pour analyser ces données par la suite.

Cela rejoint l'objectif explicite fixé au départ : si l'objectif a été formulé comme un résultat mesurable, la mesure en production est simplement le moyen de vérifier s'il a été atteint. Un consultant qui évite de s'engager sur une mesure post-déploiement, ou qui considère la livraison comme la ligne d'arrivée, mérite d'être questionné davantage.

Comment Victor Laybats aborde ces exigences

Victor Laybats propose des services d'ingénierie IA et automatisation depuis Paris et documente une approche qui va du cadrage initial au déploiement, jusqu'au suivi, plutôt que de s'arrêter à la livraison. Cette structure est décrite publiquement afin que les futurs clients puissent voir, avant de s'engager, comment un projet serait à peu près cadré et suivi.

Il vaut la peine d'être précis sur ce que cela signifie et ne signifie pas : cela décrit une approche et un ensemble de principes affirmés, pas une garantie de résultat. Comme pour tout consultant, les résultats dépendent du contexte du client, des systèmes existants et de la qualité des données concernées, et aucune affirmation allant au-delà n'est faite ici.

Un exemple concret (purement illustratif)

Prenons l'exemple hypothétique d'un détaillant de taille moyenne qui souhaite automatiser une partie de sa boîte de support client. Avant d'accepter quoi que ce soit, l'équipe métier pourrait exiger que le consultant énonce l'objectif (par exemple, réduire le temps de réponse moyen sur une catégorie définie de tickets), précise exactement à quelles données et systèmes il a besoin d'accéder et pour combien de temps, décrive où un humain pourra revoir ou corriger les réponses automatisées, et s'engage sur une période de mesure après la mise en production avec des indicateurs convenus.

Cet exemple est illustratif et ne constitue pas une affirmation sur un engagement ou un résultat réel. Son seul but est de montrer comment les quatre principes ci-dessus se traduisent en questions concrètes qu'une équipe métier peut poser lors d'une première réunion, plutôt que des hypothèses à croire sur parole.