Conseil et services en IA

Ce que le conseil et les services en IA devraient signifier pour votre organisation

Pour une équipe de direction, le conseil et les services en IA ne sont utiles que s'ils transforment une intention métier en un workflow que quelqu'un peut faire tourner, tester et arrêter. Ce libellé recouvre des offres très différentes, des ateliers de stratégie à l'intégration de modèles en passant par l'exploitation continue. Avant de comparer les prestataires, décidez lequel de ces services vous achetez et à quoi ressemble une première étape terminée.

Ces conseils viennent de Victor Laybats, ingénieur basé à Paris qui travaille sur des projets d'IA et d'automatisation, du cadrage initial au déploiement et au suivi. Ils reflètent une méthode documentée, pas une étude du marché ni un relevé de résultats clients. Voyez-les comme un moyen de poser de meilleures questions, pas comme la preuve qu'une approche donnée sera rentable dans votre contexte.

Partir d'un processus avec un responsable, pas d'un outil

L'erreur la plus fréquente consiste à commencer par « il nous faut de l'IA » ou par une plateforme préférée. Un point de départ plus solide est un seul processus décrit simplement : ce qui le déclenche, le résultat métier qu'il doit produire, qui en est responsable et quels systèmes il touche. Si personne ne peut nommer le responsable, le projet n'est pas prêt pour la mise en œuvre, quelle que soit la technologie.

Un objectif métier explicite vous autorise aussi à vous arrêter. Une bonne première mission peut conclure qu'une partie du processus doit rester manuelle parce que le volume est faible, que la part de jugement est forte, que la responsabilité est floue ou que les interfaces ne sont pas prises en charge. Cette conclusion est un livrable légitime. Elle protège l'organisation d'une démonstration impressionnante que personne ne pourra ensuite exploiter en toute sécurité.

Ce qu'une phase de découverte doit livrer avant toute ligne de code

Demandez un livrable de découverte délimité avant de valider un développement. Il rend les propositions comparables, car chaque prestataire doit décrire le même processus dans les mêmes termes concrets. Il doit aussi séparer ce qui a été observé dans votre environnement des hypothèses et des options futures, pour que vous sachiez quelles parties du plan restent des suppositions.

Les dépendances méritent une attention particulière. Certaines décisions exigent un accès personnel, l'accord d'un éditeur de logiciel ou une autorisation métier interne. Elles doivent apparaître comme des éléments visibles avec un responsable, et non être intégrées en silence dans une estimation de livraison. Voici une liste pratique pour le livrable de découverte :

• Une cartographie du workflow avec chaque étape et chaque passage de relais
• Un inventaire vérifié des intégrations concernées
• Une classification des données que le processus lit et écrit
• Les actions que l'automatisation est autorisée à effectuer, et celles qui lui sont interdites
• Les points de revue humaine et les personnes qui les assurent
• Les cas d'échec connus et un responsable de la reprise nommé
• Des non-objectifs explicites et un plan de mesure

Données maîtrisées, garde-fous et revue humaine

Un projet d'IA utile repose sur des données dont l'origine, la sensibilité et les règles d'accès sont connues. Si vous ne pouvez pas dire quels enregistrements le système peut lire, où ses résultats sont stockés et qui peut modifier ses autorisations, les garde-fous ne sont pas encore définis. La qualité compte aussi : les résultats dépendent fortement des données d'entrée, et un modèle ne peut pas compenser des données sources manquantes ou incohérentes.

La revue humaine n'est pas le signe d'une automatisation faible ; c'est ce qui garde visibles les décisions qui restent humaines. Placez la revue là où une erreur coûterait cher ou serait difficile à corriger, par exemple avant qu'un message n'atteigne un client ou avant la modification d'un enregistrement dans un système de référence. La conception doit rendre évident le moment où le système est incertain et la façon dont une personne reprend la main.

Mesurer en production et connaître les limites

Un prototype ou une architecture de référence peut expliquer une méthode, mais ne prouve ni un retour sur investissement, ni un gain de temps, ni un résultat client. Convenez avant le lancement de ce qui sera mesuré une fois le workflow confronté au trafic réel : taux d'erreur, part des cas envoyés en revue, temps de traitement, ou tout indicateur relié à l'objectif annoncé. Sans point de référence établi avant le changement, toute amélioration revendiquée ensuite est difficile à vérifier.

Méfiez-vous de tout prestataire qui promet des gains fixes. Les résultats dépendent de vos systèmes existants, de vos processus et de la qualité des données d'entrée. De même, être associé à un studio ou figurer dans un portfolio n'implique ni recommandation ni résultat garanti ; les capacités actuelles doivent être vérifiées directement. Les questions juridiques ou réglementaires concernant vos données doivent être confiées à des conseillers qualifiés.

Exemple : cadrer une demande hypothétique de tri des factures

Exemple hypothétique, pas un cas client : une équipe financière demande « de l'IA pour gérer les factures fournisseurs ». La découverte réduit la demande à un seul processus : les factures reçues par e-mail sont classées et rapprochées des bons de commande, sous la responsabilité du responsable de la comptabilité fournisseurs. La cartographie montre que la boîte mail et l'outil comptable disposent d'interfaces exploitables, mais que les règles d'approbation se trouvent dans un tableur que personne ne maintient.

Le périmètre qui en résulte n'automatise que l'extraction et le rapprochement. Toute facture au-dessus d'un seuil convenu, ou toute incohérence, est confiée à une personne ; l'approbation des paiements reste manuelle et est déclarée comme non-objectif. Le plan de mesure compare la précision du rapprochement et le volume de revue à quelques semaines de référence manuelle. Si le tableur ne peut pas être remis en ordre, la recommandation est de clarifier d'abord la responsabilité et de revenir à l'automatisation plus tard.