De l’acheteur au développeur IA : ce que le métier change

Retour terrain · 7 min

J’ai travaillé près de dix ans dans les achats avant de construire des systèmes IA. Ce parcours peut sembler être une reconversion. Dans la pratique, c’est la continuité qui compte le plus.

Un processus métier n’est pas une succession propre d’étapes. Il vit dans les exceptions, les responsabilités implicites et les arbitrages que personne n’a écrits. C’est précisément là que les projets IA échouent.

Le métier apprend à chercher le coût réel

Dans un processus achats, deux heures de saisie ne sont pas toujours le principal problème. Le coût peut venir d’une décision retardée, d’une information impossible à vérifier ou d’une négociation préparée avec une vision incomplète.

Avant d’automatiser, je cherche donc :

• où le travail attend ;
• où une information est recopiée ;
• où une erreur devient coûteuse ;
• où une personne compense silencieusement le système.

Cette cartographie évite de construire une solution rapide sur la mauvaise étape.

La technique apprend à rendre les hypothèses testables

L’expérience métier donne des intuitions. Elle ne les rend pas vraies. Le développement oblige à les traduire en comportements observables.

« Le système comprend le contrat » ne veut rien dire tant que nous n’avons pas défini :

1. les clauses qu’il doit retrouver ;
2. les variantes qu’il doit reconnaître ;
3. les sources qu’il doit citer ;
4. les cas où il doit demander de l’aide ;
5. la personne qui décide si la sortie est suffisante.

C’est ce passage de l’intuition au test qui transforme un prototype en produit de travail.

L’adoption ne vient pas après la livraison

Un outil peut être techniquement correct et rester inutilisé. Souvent, il interrompt les habitudes sans expliquer ce qu’il sécurise.

L’utilisateur doit comprendre :

• ce que le système a fait ;
• ce qu’il n’a pas vérifié ;
• pourquoi il demande une validation ;
• comment corriger une sortie ;
• ce que devient cette correction.

La transparence n’est pas seulement une exigence de conformité. C’est une composante de l’expérience utilisateur.

Mon rôle se situe entre trois langues

Je traduis entre le besoin métier, les contraintes du système et la décision de l’organisation.

• Au métier : ce que l’IA peut préparer de manière fiable.
• À la technique : les exceptions qui ont une conséquence réelle.
• À la direction : la valeur, le risque et les conditions de déploiement.

Cette position évite deux erreurs symétriques : demander au modèle de résoudre un problème organisationnel, ou construire une architecture parfaite pour une friction secondaire.

Ce que je ferais avant tout projet IA

Je passerais une journée à observer le processus réel. Pas la procédure officielle : le travail tel qu’il se fait avec ses raccourcis, ses fichiers intermédiaires et ses demandes urgentes.

Puis je choisirais une seule décision à améliorer et un critère permettant de dire, rapidement, si le système aide vraiment.

La technologie vient ensuite.

Vous avez identifié un processus mais pas encore le bon point d’entrée ? Cadrons-le ensemble.