Cas d'usage IA en entreprise : de la définition au déploiement en production

Pourquoi tant de PoC IA ne passent jamais en production

Un proof of concept d'intelligence artificielle est facile à lancer : un jeu de données extrait à la main, un modèle du marché, un notebook, une démonstration convaincante devant le comité de direction. Puis viennent les questions qui n'ont pas été posées au départ : quelle valeur mesurable ? Quelles données en continu, avec quels droits ? Qui porte le système une fois en production ? Que dit le règlement européen sur l'IA pour ce type d'usage ?

Ces questions ne sont pas techniques. Ce sont des questions de cadrage et de direction de programme. Un cas d'usage IA réussi se traite comme n'importe quel programme IT : un périmètre, une valeur attendue, des jalons de décision, un budget, des risques, et un handover vers l'exploitation préparé dès le premier jour.

Phase 1 — Identifier les cas d'usage : partir des processus, pas des modèles

La question « que pourrait-on faire avec l'IA ? » produit des listes de gadgets. La question « où perdons-nous du temps, de l'argent ou de la qualité, et quelle information nous manque pour décider ? » produit des cas d'usage. Nous animons donc l'identification processus par processus, avec les équipes qui les font vivre : opérations, maintenance, commerce, support, finance, qualité.

Trois familles de cas d'usage

• Automatisation documentaire : extraction et classification d'informations dans des rapports, contrats, factures, tickets ; génération de comptes rendus ou de premières versions de documents.
• Aide à la décision et prédiction : maintenance prédictive d'actifs industriels, prévision de charge ou de demande, détection d'anomalies sur des données IoT, scoring de risques.
• Assistants et IA générative : assistants conversationnels sur la documentation technique (RAG), aide à la rédaction d'offres, copilotes pour les équipes support ou ingénierie.

Dans l'énergie et les services industriels, les cas d'usage les plus solides combinent souvent les trois : lecture automatique de rapports d'inspection, priorisation des interventions à partir des données capteurs, assistant qui répond aux techniciens à partir des procédures internes.

Phase 2 — Qualifier : la matrice valeur / faisabilité

Un portefeuille de vingt idées ne se finance pas. La qualification consiste à positionner chaque cas d'usage sur trois axes et à ne retenir que ceux qui tiennent sur les trois.

1. La valeur

• Gain mesurable : heures économisées, taux d'erreur, délai de traitement, revenu additionnel, pénalités évitées.
• Volume : combien de fois par mois le processus s'exécute-t-il ? Un gain unitaire élevé sur un processus rare vaut moins qu'un petit gain sur un flux quotidien.
• Un indicateur de succès chiffré, mesuré avant le projet pour disposer d'une référence.

2. La faisabilité

• Données : existent-elles, en quel volume, avec quelle qualité, quelle historique ? Qui en est propriétaire ? Peut-on les utiliser pour cet usage (finalité, contrats, RGPD) ?
• Intégration : où le résultat du modèle doit-il arriver — dans l'outil métier, dans SAP, dans une application mobile terrain ? Une prédiction que personne ne voit ne vaut rien.
• Complexité : un modèle du marché suffit-il, ou faut-il entraîner un modèle spécifique ? Les données sont-elles multilingues, multimodales, sensibles ?

3. Le risque et la conformité

• AI Act : le règlement européen classe les systèmes d'IA par niveau de risque. Un assistant de rédaction et un système qui influence des décisions relatives aux personnes n'ont pas les mêmes obligations (documentation, supervision humaine, transparence). La classification se fait au cadrage, pas après le pilote.
• RGPD et confidentialité : données personnelles, données clients, secrets industriels transmis à un fournisseur de modèles — les flux doivent être cartographiés.
• Risque opérationnel et réputationnel : que se passe-t-il quand le modèle se trompe ? Qui vérifie, avec quel processus de recours ?

Le résultat de cette phase est un portefeuille priorisé : trois à cinq cas d'usage à forte valeur et faisabilité démontrée, avec pour chacun un business case, une fiche de risques et un propriétaire métier nommé.

Phase 3 — Implémenter : make-or-buy, PoC, pilote

La décision make-or-buy

Avant d'écrire une ligne de code, il faut choisir la voie d'implémentation. Trois options dominent, et le bon choix dépend de la différenciation attendue, du délai et de la dépendance acceptable.

Option	Délai	Différenciation	Dépendance	Quand la choisir
Fonction IA d'un éditeur (déjà intégrée à un outil en place)	Semaines	Faible	Forte (roadmap éditeur)	Processus standard, outil déjà déployé, gain rapide recherché
Modèle du marché via API (LLM, vision, RAG sur vos documents)	Semaines à quelques mois	Moyenne (vos données, vos prompts, votre intégration)	Moyenne (interchangeable si l'architecture l'anticipe)	Cas d'usage documentaires et conversationnels, données textuelles internes
Développement spécifique (modèle entraîné sur vos données)	Plusieurs mois	Forte	Faible (mais compétences internes nécessaires)	Données propriétaires uniques, avantage concurrentiel, contraintes de confidentialité fortes

PoC puis pilote : deux objets différents

Le PoC répond à une seule question : « est-ce techniquement faisable sur nos données réelles, avec une qualité suffisante ? ». Il dure quelques semaines, travaille sur un extrait de données représentatif et se termine par une décision go / no-go documentée.

Le pilote répond à une autre question : « le processus fonctionne-t-il mieux avec le système, pour de vrais utilisateurs, dans de vraies conditions ? ». Il s'exécute sur un périmètre limité (un site, une équipe, une famille de documents), mesure l'indicateur défini en phase 2 et éprouve l'intégration, la supervision humaine et le support. Ses critères de sortie sont fixés avant son démarrage.

Phase 4 — Déployer : industrialiser, gouverner, faire adopter

Industrialiser (MLOps / LLMOps)

• Pipelines de données reproductibles, versionnage des données, des modèles et des prompts.
• Supervision en production : qualité des réponses, dérive des données, temps de réponse, coûts d'inférence par usage.
• Évaluation continue : jeux de tests métier, seuils d'alerte, procédure de retour arrière.

Sécuriser

• Cloisonnement des données sensibles, gestion des accès, journalisation des requêtes.
• Pour l'IA générative : protection contre l'injection de prompts, filtrage des sorties, limites d'usage.
• Choix d'hébergement cohérent avec la classification des données (cloud public, région, instance dédiée).

Gouverner

• Registre des systèmes d'IA en production : finalité, niveau de risque AI Act, propriétaire, données utilisées, date de revue.
• Documentation technique et notice d'utilisation, supervision humaine définie, information des utilisateurs lorsque le règlement l'exige.
• Comité de revue périodique : performance, incidents, évolutions réglementaires, décision de maintenir, corriger ou retirer.

Faire adopter

• Le processus métier est redessiné avec le système, pas simplement « augmenté » : qui fait quoi, qui valide, que devient le temps libéré.
• Formation ciblée par rôle, ambassadeurs dans les équipes, mesure de l'usage réel.
• Un sponsor métier qui rend compte de l'indicateur de valeur — pas seulement la DSI.

Organiser le RUN

Un système d'IA n'est jamais « terminé » : les données évoluent, les modèles du marché changent de version, les usages se déplacent. Le déploiement inclut donc un modèle de RUN : un propriétaire produit, un budget d'exploitation (dont les coûts d'inférence), un niveau de service, un support de premier niveau et une feuille de route d'amélioration.

Piloter l'IA comme un programme, pas comme une expérimentation

Ce qui distingue les organisations qui déploient réellement l'IA de celles qui accumulent les démonstrateurs, c'est la gouvernance de programme : un portefeuille de cas d'usage priorisé, des jalons go / no-go entre chaque phase, un budget qui couvre le déploiement et le RUN — pas seulement le PoC — et une seule équipe responsable du cadrage jusqu'au handover.

• Cadrer : portefeuille, business cases, classification des risques, roadmap.
• Décider : make-or-buy, sélection des fournisseurs, contrats, gouvernance.
• Piloter : PoC, pilotes, intégration, reporting sponsors, décisions documentées.
• Transférer : industrialisation, formation, registre IA, modèle de RUN.

Conclusion : la valeur se décide au cadrage

Les modèles progressent vite et deviennent accessibles à tous ; ils ne constituent plus l'avantage. L'avantage réside dans la capacité à choisir les bons cas d'usage, à les qualifier honnêtement, à trancher make-or-buy sans dogme et à conduire le déploiement jusqu'à l'adoption. C'est un travail de direction de programme — celui pour lequel RBL Advisory intervient.