Un premier projet IA commence par le métier

On pense souvent qu’un projet d’IA commence par le choix d’un outil, la configuration d’un agent ou la construction d’un prototype.

En réalité, il commence beaucoup plus tôt : par la compréhension du travail réel.

C’est l’une des principales leçons que je retiens de notre premier projet d’IA. Le sujet n’était pas de savoir si la technologie pouvait fonctionner. Le sujet était de savoir comment l’intégrer dans une activité professionnelle concrète, avec ses tâches, ses contraintes, ses utilisateurs et ses responsabilités.

Regarder la vidéo 

Le problème n’était pas forcément la solution

Dans ce premier projet, les cas d’usage identifiés étaient pertinents. L’architecture générale était cohérente. Pourtant, le projet a rencontré plusieurs difficultés au fur et à mesure de sa mise en œuvre.

Certaines fonctionnalités ont dû être recalibrées. Les accès techniques n’avaient pas été suffisamment vérifiés. Le rôle de l’utilisateur final devait être mieux défini. Et le fonctionnement réel du métier n’avait pas été observé avec assez de précision pour concevoir un dispositif réellement intégré au quotidien.

Ce type de situation est fréquent. Une équipe peut avoir une bonne idée, choisir des outils adaptés et produire une première solution fonctionnelle, tout en ayant commencé trop tôt.Le problème n’est alors pas nécessairement que la solution est à côté du sujet. Elle peut répondre au bon besoin, mais dans un périmètre encore trop flou et avec des conditions de mise en œuvre insuffisamment sécurisées.

Ce que nous avons changé

Nous avons repris la démarche dans un ordre plus robuste.

1. Comprendre le travail réel

Avant de concevoir l’agent, il faut comprendre ce que la personne fait réellement :

1. quelles tâches revient-elle effectuer ?
2. quelles informations consulte-t-elle ?
3. quelles décisions prend-elle ?
4. avec quels outils travaille-t-elle ?
5. où se situent les pertes de temps, les erreurs et les irritants ?

L’objectif n’est pas de produire un schéma théorique. Il faut comprendre le travail tel qu’il est réellement effectué.

2. Définir le rôle de l’agent

Un agent ne doit pas être présenté comme une solution générale capable de tout faire.Il faut préciser :

1. ce qu’il doit aider à faire ;
2. les informations qu’il peut utiliser ;
3. les réponses qu’il peut produire ;
4. les limites qu’il doit respecter ;
5. les décisions qui restent humaines ;
6. les situations dans lesquelles il doit demander une validation.

Cette étape permet de considérer l’agent comme un collaborateur outillé, avec un rôle, un périmètre et des responsabilités clairement définis.

3. Vérifier les conditions de mise en œuvre

Un projet peut être pertinent sur le papier et rester bloqué par des conditions très concrètes :

1. droits d’accès ;
2. comptes utilisateurs ;
3. formats de fichiers ;
4. qualité des données ;
5. règles de sécurité ;
6. outils réellement disponibles ;
7. contraintes de confidentialité ;
8. disponibilité des utilisateurs pour tester.

Ces points doivent être vérifiés avant de promettre une intégration ou de développer trop loin.

4. Réduire le périmètre

Le premier projet n’a pas besoin de traiter tout le métier.Il vaut mieux choisir une tâche suffisamment fréquente, suffisamment claire et suffisamment observable pour être testée rapidement.Un périmètre réduit permet de répondre à une question essentielle : le dispositif apporte-t-il une aide réelle dans cette situation précise ?

5. Construire par lots et tester avec l’utilisateur

Une solution ne devient pas utile simplement parce qu’elle fonctionne techniquement.Elle doit aussi être comprise, testée et appropriée par la personne qui va l’utiliser. La construction doit donc être progressive, avec des retours réguliers, une recette fonctionnelle et des ajustements fondés sur des situations réelles.C’est cette boucle qui permet de passer d’une démonstration intéressante à un usage qui trouve sa place dans le travail.

Les six questions à poser avant de construire

Avant de commencer un premier projet, il est utile de répondre clairement à ces six questions :

1. Quel problème métier cherchons-nous à traiter ?
2. Qui rencontre ce problème aujourd’hui ?
3. Quelles tâches et quelles informations sont réellement concernées ?
4. Quelles données et quels accès sont disponibles ?
5. Quel est le plus petit périmètre que nous pouvons tester ?
6. Comment saurons-nous que le test est utile ?

Si plusieurs réponses restent floues, il est probablement trop tôt pour choisir un outil ou construire un agent.

En résumé : Avant de demander quelle IA utiliser, il faut savoir quel problème mérite vraiment d’être traité.

Regarder la video