Conduire un projet d'IA

Partir du problème, jamais de la technologie

La cause la plus fréquente d'échec n'est ni technique ni budgétaire : c'est d'avoir choisi la solution avant le problème. « Nous voulons faire de l'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire » n'est pas un cahier des charges.

Un bon cas d'usage se reconnaît à quatre traits :

• une tâche répétitive, exécutée souvent et consommant du temps ;
• des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire existantes, déjà collectées dans le cadre de l'activité ;
• une erreur tolérable, détectable et corrigeable ;
• un gain mesurable, quantifiable avant le lancement.

Si l'un manque, l'examen mérite d'être poussé avant d'engager quoi que ce soit.

Un cas concret : le tri des demandes entrantes

Une direction clientèle reçoit 12 000 messages par mois. Quatre agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire les classent manuellement en huit catégories avant affectation. Le temps moyen de tri est de 90 secondes. Le projet candidat : un classifieur qui propose une catégorie, l'agent confirmant ou corrigeant.

Vérification des quatre traits :

Ce cas est typique d'un gain rapide. Il n'exige ni modèle sur mesure ni lac de données. Il exige en revanche une référence mesurée (temps et taux d'erreur actuels) et un critère d'arrêt explicite.

Si vous ne pouvez pas écrire en une phrase le problème, le gain attendu et le seuil en deçà duquel vous abandonnez, vous n'avez pas encore de projet : vous avez une intention.

Qualifier la faisabilité

La faisabilité ne se juge pas à la sophistication du modèle. Elle se juge à quatre questions plus prosaïques :

1. Les données couvrent-elles les cas difficiles, pas seulement les cas moyens ?
2. L'étiquetageétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire peut-il être produit en volume raisonnable, avec un accord inter-annotateurs mesurable ?
3. Le système s'intègre-t-il au flux de travail existant sans refonte lourde ?
4. Existe-t-il une personne métier propriétaire du résultat, pas seulement un sponsor de démarrage ?

Le premier projet ne doit pas être le plus ambitieux. Un cas d'usage modeste, mené jusqu'en production et mesuré, apprend à l'organisation ce qu'aucune étude ne lui apprendra : la qualité réelle de ses données, le temps d'étiquetage, les résistances internes. Ces enseignements conditionnent la réussite des projets suivants.

Acheter, adapter ou construire

Construire depuis zéro se justifie rarement. La plupart des besoins se traitent en adaptant un modèle existant, pour une fraction du coût.

Trois questions tranchent souvent le débat plus vite qu'un appel d'offres :

• Le besoin est-il générique ? Transcription, OCR, traduction : un service mature suffit presque toujours.
• La valeur est-elle dans vos données ? Classification métier, recherche interne, détection de motifs propres : adapter.
• Avez-vous une contrainte de souveraineté ou de rareté ? Alors seulement envisager un entraînement complet — et budgéter l'annotationannotationIAProcessus d'étiquetage manuel des données d'entraînement par des experts humains. La qualité de l'annotation conditionne directement les performances du modèle d'apprentissage supervisé.Voir dans le glossaire avant les GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire.

Vérifiez les conditions d'utilisation avant tout envoi de données à un service en ligne : les contenus soumis peuvent-ils servir à l'entraînement, où sont-ils hébergés, combien de temps sont-ils conservés ? Une démonstration réussie avec des données réelles peut constituer une violation de confidentialité — voire un transfert hors Union européenne non encadré.

Définir la mesure avant de commencer

Un projet sans critère d'arrêt défini à l'avance ne s'arrête jamais. Fixez, avant le premier développement :

• l'indicateur métier — temps gagné, taux d'erreur, volume traité ;
• le seuil d'acceptation — en deçà duquel le projet est abandonné ;
• la référence de comparaison — la performance du processus actuel, mesurée et non estimée ;
• la durée d'évaluation — au-delà de laquelle on tranche.

Sur le cas du tri des messages, une référence crédible pourrait être :

Le seuil d'erreur peut sembler « moins bon » que l'humain. Ce n'est pas un problème si le temps gagné reste net et si la confirmation humaine corrige les cas douteux. L'objectif n'est pas de battre le meilleur agent : c'est d'améliorer le processus global.

Comparez toujours au processus existant, pas à la perfection. Un modèle qui atteint 85 % de réussite là où la procédure manuelle plafonne à 78 % constitue un progrès, même si le chiffre paraît modeste. Sans référence mesurée, aucune décision d'investissement n'est fondée.

Du prototype à la production

Le prototype répond à une seule question : est-ce techniquement plausible sur nos données ? La production répond à d'autres questions : latence, journalisation, droits d'accès, reprise sur erreur, supervision, procédure de recours.

Quatre écarts classiques entre démo et production :

1. Les données de démo sont trop propres. Les pièces jointes corrompues, les messages bilingues et les doublons apparaissent après.
2. La latence acceptable en atelier ne l'est pas au guichet. Une réponse en huit secondes casse un flux téléphonique.
3. Personne n'a défini qui corrige le modèle. Sans propriétaire métier, les erreurs s'accumulent sans remonter.
4. La conformité arrive en fin de parcours. La qualification AI ActAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire et la base légale des données doivent précéder l'industrialisation, pas la suivre.

Un pilote utile dure assez longtemps pour voir la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire et les cas rares — souvent six à douze semaines — et reste assez étroit pour pouvoir être arrêté sans drame organisationnel.

Les conditions humaines

Un projet d'IA modifie des façons de travailler. Trois points le déterminent autant que la technique :

Associer les métiers dès le départ. Ceux qui exécutent la tâche savent quels cas particuliers font échouer les règles. Leur expertise est irremplaçable au moment de l'étiquetage comme de l'évaluation.

Énoncer clairement l'intention. Un outil présenté sans explication est perçu comme une menace sur l'emploi, et l'adoption s'en ressent durablement.

Préserver la compétence. Si les opérateurs perdent la capacité d'accomplir la tâche sans l'outil, ils deviennent incapables de détecter ses erreurs — et le contrôle humain devient fictif.

Bonne pratique. Planifiez dès le cadrage des plages où l'outil est volontairement désactivé, ou des lots traités à la main. Ce n'est pas du freinage : c'est l'entretien de la capacité de contrôle, sans laquelle la supervision humaine n'est qu'une case cochée.

Une trame de projet

1. Cadrer — problème, gain attendu, critère d'arrêt.
2. Auditer les données — disponibilité, qualité, base légale.
3. Qualifier le risque — au sens de l'AI Act, avant tout développement.
4. Prototyper vite, sur un périmètre restreint et des données réelles.
5. Évaluer contre la référence mesurée, avec les métiers.
6. Décider : industrialiser, réorienter, ou arrêter — les trois issues sont légitimes.
7. Déployer avec journalisation, supervision humaine et procédure de recours.
8. Surveiller la dérive et réentraîner.

Chaque étape a un livrable écrit. Sans livrable, l'étape n'a pas eu lieu : une réunion d'alignement ne remplace pas un critère d'arrêt signé, pas plus qu'un notebook ne remplace une évaluation contradictoire avec les métiers.

Six idées reçues à écarter

« Il nous faut d'abord un lac de données. » Non. Un projet ciblé n'exige que les données de son périmètre. Les programmes qui commencent par centraliser toutes les données de l'entreprise mettent des années à produire leur premier résultat utile.

« Plus le modèle est gros, meilleur il est. » Le modèle le plus volumineux n'est pas le mieux adapté à toutes les tâches. Un modèle plus petit, spécialisé, coûte moins cher, répond plus vite et suffit souvent — d'autant que la latence pèse fortement sur l'adoption.

« L'IA va supprimer ce poste. » Les observations sur le terrain montrent plutôt un déplacement des tâches : moins de production initiale, davantage de vérification et d'arbitrage. Le métier change de contenu avant de disparaître.

« C'est une question technique. » La réussite dépend avant tout de la qualité des données existantes, de l'étroitesse du périmètre et de l'association des équipes métier. La technologie est rarement le facteur limitant.

« On verra la conformité plus tard. » La qualification au sens de l'AI Act détermine des obligations de conception — documentation, contrôle humain, journalisation. Les découvrir après le développement impose de reprendre l'architecture.

« Le fournisseur s'occupe de tout. » Le déployeur conserve ses propres obligations, et peut basculer dans le statut de fournisseur s'il modifie substantiellement le système ou le commercialise sous sa marque.

Estimer le retour sur investissement

Un calcul honnête compare trois grandeurs sur douze mois :

Deux corrections s'imposent presque toujours :

• Le gain n'est jamais total. Si le système traite 70 % des cas et que la vérification prend 20 % du temps initial, le gain réel avoisine 56 %, pas 70 %.
• Le coût de vérification ne disparaît pas. Il diminue à mesure que la confiance s'installe, mais le supprimer entièrement revient à supprimer le contrôle.

Sur le tri des messages : 300 h/mois × 0,56 ≈ 168 h gagnées, moins le temps de supervision et de réétiquetage. Si ce solde reste positif après six mois de coûts récurrents, le projet tient. S'il ne tient que dans un tableur où la vérification vaut zéro, il ne tient pas.

Un projet dont le retour sur investissement ne tient que sans vérification humaine n'est pas rentable : il est simplement mal évalué. Intégrez ce coût dès le calcul initial — c'est ce qui distingue une estimation crédible d'une projection commerciale.

Pour aller plus loin

Cette formation vous a donné le vocabulaire et les repères pour dialoguer utilement avec des équipes techniques et évaluer une proposition. Les suites naturelles : approfondir la gouvernance des données, la sécurité des systèmes d'IA, ou la mise en œuvre pratique du RAG sur un corpus documentaire interne.

Qui décide, qui corrige

Un projet d'IA sans rôles clairs s'enlise après la démo. Quatre responsabilités minimales :

Le point critique n'est pas la charte : c'est le propriétaire des erreurs en production. Sans lui, les faux positifs s'accumulent dans une file que personne ne traite, et le système pourrit en silence.

Du problème métier au critère de succès

Un projet d’IA commence par une décision à améliorer, pas par un modèle à placer. Formalisez : qui décide quoi, avec quelle information, à quelle fréquence, avec quel coût d’erreur. Ensuite seulement choisissez données et technique.

Définissez le MVP : périmètre étroit, métrique unique, durée de pilote, critères go/no-go. Sans no-go explicite, tout pilote « continue par inertie ».

Organisation et rôles

Sponsor métier, product owner, data/MLapprentissage automatiqueIABranche de l'IA où le programme dégage lui-même ses règles à partir d'exemples, au lieu de les recevoir d'un développeur. C'est ce déplacement des règles écrites vers les régularités apprises qui définit l'IA moderne.Voir dans le glossaire, ingénierie, sécurité, conformité, ops : même sur un petit projet, ces casquettes existent. Une seule personne peut en porter plusieurs, mais aucune ne doit être oubliée. Clarifiez qui arrête le système en cas d’incident.

Roadmap pragmatique

Semaines 1–2 : cadrage et données disponibles. Semaines 3–6 : baseline simple et évaluation honnête. Semaines 7–10 : intégration et supervision. Ensuite : monitoring et itération. Ajustez, mais gardez des jalons où l’on peut tuer le projet sans perte de face.

Un projet IA réussi est d’abord un projet produit et ops, ensuite un projet modèle.

Checklist de go-live

Métriques validées hors démo, droits d’accès, logs, rollback, runbook, formation utilisateurs, canal de feedback, owner nommé. Si un item manque, vous n’êtes pas en go-live : vous êtes en expérimentation exposée.

Publiez une « définition de terminé » écrite avant le premier sprint technique.

Kill criteria et revue à 90 jours

Définissez à l’avance les seuils qui arrêtent le projet : métrique insuffisante, coût hors budget, incident de sécurité, non-conformité. Planifiez une revue à 90 jours avec chiffres de production. Renouveler un abonnement cloud « parce que c’est déjà là » n’est pas une stratégie.

Artefacts livrables d’un pilote sérieux

Cadrage d’une page, data card, protocole d’évaluation, résultats chiffrés, risques, décision go/no-go, plan d’intégration, runbook. Si un de ces artefacts manque à la fin du pilote, vous avez une démo, pas un pilote. Archivez-les avec la version du modèle : votre futur vous remerciera lors de l’incident ou de l’audit.