Par où commencer quand on n'a jamais fait d'IA

Le projet commence par « nous voulons faire de l'IA ». C'est un objectif de moyen, pas de résultat, et c'est la cause d'échec la plus courante.

Un projet qui démarre ainsi produit une démonstration : quelque chose qui fonctionne, que l'on montre en comité, et que personne n'utilise trois mois plus tard. Le système n'était pas mauvais — il ne répondait à rien.

L'ordre correct est l'inverse : un problème d'abord, une technologie ensuite, et parfois la conclusion que la technologie n'est pas la réponse.

Une phrase, sans jargon, qui décrit ce qui coûte du temps ou de l'argent aujourd'hui.

• « Trois personnes passent leur journée à ressaisir des factures »
• « On rate les messages clients du soir et du week-end »
• « On découvre les incidents le lendemain »
• « On ne sait pas quel produit est réellement rentable »

Si vous ne pouvez pas écrire cette phrase, arrêtez-vous ici. Ce n'est pas un échec : c'est une information. Il faut d'abord observer où part le temps.

Un test simple : demandez à trois personnes de votre équipe quelle tâche elles trouvent la plus absurde dans leur semaine. Les réponses se recoupent presque toujours.

Un agent s'entraîne sur ce qui existe. C'est le point de blocage le plus fréquent, et il n'est pas technique.

Vos procédures sont-elles écrites ? Si les règles de votre métier vivent uniquement dans la tête de trois personnes, il n'y a rien à indexer. Le premier travail est de les écrire — et il a de la valeur même sans IA.

Vos documents sont-ils accessibles ? Un dossier partagé avec des PDF suffit. Un classeur papier demande d'abord une numérisation.

Vos indicateurs ont-ils une définition unique ? Si « client actif » signifie autre chose au commerce qu'à la comptabilité, aucun outil ne les réconciliera.

Pour la vision : vos caméras couvrent-elles la zone concernée, avec un angle exploitable ? L'angle compte davantage que la résolution.

C'est la question qu'on oublie, et celle qui tue le plus de projets après coup.

Un agent produit une alerte, un chiffre, une réponse. Qui la reçoit, et que fait-il ?

• Une alerte d'intrusion à 3 h du matin : qui la voit, qui se déplace ?
• Une anomalie de facturation : qui la traite, sous quel délai ?
• Un rapport quotidien : qui le lit, quelle décision en découle ?

Si la réponse n'est pas une personne ou un rôle nommé, le système produira du bruit. Un système qui alerte sans que personne ne réagisse coûte plus cher qu'un système absent, parce qu'il donne l'illusion d'être couvert.

Un critère de réussite, écrit avant de commencer, chiffré si possible.

• « Le temps de traitement d'une facture passe sous X minutes »
• « Plus de la moitié des messages clients reçoivent une réponse sans intervention »
• « Les incidents nocturnes sont signalés dans la nuit, pas le lendemain »

Sans ce critère, la discussion de fin de projet devient une affaire d'impression. Et une impression, ça se conteste.

Le processus change tous les mois. Automatiser un processus instable revient à figer du désordre. Stabilisez d'abord.

Personne n'est disponible pour cadrer. Un projet d'IA demande quelques heures d'une personne qui connaît le métier. Sans elle, le cadrage se fait sur des suppositions.

Le budget est calculé sur un objectif de communication. « Il nous faut de l'IA pour l'image » produit des projets qui ne servent pas.

• Une tâche, un périmètre restreint. Un type de document, un canal, une zone.
• Un pilote en conditions réelles, en parallèle du traitement actuel, pour comparer.
• Une mesure, contre le critère écrit au départ.
• Puis on étend — ou on arrête, et c'est une décision saine.

Comptez 4 à 8 semaines entre le cadrage et la mise en production.

La partie difficile d'un projet d'IA n'est presque jamais le modèle. C'est de savoir quel problème on résout, avec quelle matière, pour qui, et comment on saura que ça a marché. Ces quatre réponses valent plus que le choix de la technologie.