Depuis trois ans, les organisations françaises ont massivement expérimenté l'intelligence artificielle générative. Beaucoup moins nombreuses sont celles qui peuvent aujourd'hui citer un usage installé, mesuré, et intégré à leurs procédures. Cet écart entre l'expérimentation et l'exploitation est le vrai sujet.
Le constat de départ
Un projet d'IA échoue rarement pour des raisons techniques. Les modèles disponibles aujourd'hui sont largement suffisants pour l'immense majorité des besoins d'une PME ou d'une administration. Les causes d'échec sont ailleurs, et elles sont remarquablement stables d'une organisation à l'autre :
- le cas d'usage a été choisi pour sa démonstrabilité, pas pour sa valeur ;
- aucun propriétaire métier n'a été désigné, seulement un sponsor lointain ;
- le critère de succès n'a jamais été écrit, donc le projet ne peut ni réussir ni échouer ;
- la conformité a été traitée après le développement, ce qui a bloqué la mise en production ;
- l'adoption a été considérée comme un problème de communication.
La méthode qui suit ne prétend pas être originale. Elle est simplement ordonnée, et cet ordre compte davantage que le contenu de chaque étape.
1. Partir des processus, pas des outils
La question « que pourrait-on faire avec l'IA ? » produit systématiquement des réponses inutilisables. La bonne question est : où passe le temps de nos équipes, et lequel de ces temps est répétitif, documenté, à faible valeur ajoutée et à faible risque ?
Concrètement, cela veut dire aller observer. Une demi-journée passée à côté d'un chargé d'affaires qui monte un devis vous apprendra plus que trois réunions de cadrage. Vous verrez qu'il ouvre sept onglets, qu'il recopie manuellement des références, qu'il cherche pendant douze minutes un document technique qu'il sait exister quelque part.
Ces gestes-là sont les bons candidats. Ils sont fréquents, chronométrables, et leur amélioration se traduit immédiatement en heures.
Un cas d'usage qu'on ne peut pas chiffrer en heures par semaine n'est pas encore un cas d'usage. C'est une idée.
2. Prioriser avec une grille honnête
Une fois vingt à quarante cas d'usage identifiés, il faut trancher. Nous utilisons quatre axes, notés de 1 à 5 :
| Axe | Question posée | Piège fréquent |
|---|---|---|
| Impact | Combien d'heures ou d'euros par an ? | Compter des gains théoriques jamais réalloués |
| Effort | Combien de semaines-personne, intégrations comprises ? | Oublier le coût des connexions aux systèmes existants |
| Risque | Que se passe-t-il si le système se trompe ? | Sous-estimer les cas touchant à des personnes |
| Maturité de la donnée | La matière existe-t-elle, propre et accessible ? | Découvrir en semaine 6 que la GED est un chaos |
Ce qui compte n'est pas la précision de la notation, forcément approximative, mais le fait que l'arbitrage devienne explicite et discutable. Un directeur qui voit son cas d'usage favori noté 2 sur l'axe « maturité de la donnée » comprend ce qu'il doit faire pour le remonter.
Retenez trois à cinq cas d'usage. Pas dix. Une organisation ne peut pas conduire dix changements simultanés.
3. Poser le cadre avant de coder
Le cadre, c'est trois documents courts, produits en quelques jours :
- une classification des données : ce qui peut être transmis à un service externe, ce qui doit rester dans un environnement maîtrisé, ce qui ne doit jamais être traité automatiquement ;
- une charte d'usage interne : ce que les collaborateurs ont le droit de faire, avec quels outils, et ce qui est proscrit ;
- une note de conformité : base légale des traitements, information des personnes, positionnement au regard du règlement européen sur l'IA, et supervision humaine prévue.
Ces documents ne sont pas des formalités administratives. Ils déterminent l'architecture technique. Un cas d'usage qui manipule des données RH n'a pas la même conception qu'un assistant de recherche documentaire sur des fiches produits publiques.
4. Construire un pilote qui peut échouer
Un bon pilote a quatre propriétés : un périmètre étroit, des utilisateurs volontaires, une durée bornée, et un critère d'arrêt écrit à l'avance.
Le critère d'arrêt est le plus souvent oublié, et c'est le plus important. Écrivez, avant de commencer : « si au bout de huit semaines moins de la moitié des utilisateurs pilotes s'en servent au moins trois fois par semaine, nous arrêtons ». Cette phrase transforme le pilote en expérience, et une expérience qui échoue est un résultat, pas une faute.
Sur le plan technique, visez la qualité de production dès le pilote. Une interface bâclée produit un rejet qui n'a rien à voir avec la pertinence du cas d'usage, et vous ne saurez plus ce que vous avez testé.
5. Traiter l'adoption comme un chantier à part entière
C'est ici que se joue l'essentiel, et c'est ici que la plupart des budgets sont sous-dimensionnés. Quelques principes qui fonctionnent :
- Former sur les documents réels de l'entreprise. Une formation générique sur les « prompts » ne produit aucun transfert. Une session où l'on retraite ensemble trois dossiers de la semaine précédente, si.
- Nommer des référents légitimes. Le meilleur relais n'est pas le plus technophile, c'est celui que les autres vont voir spontanément quand ils ont une question métier.
- Répondre à la question de l'emploi. Elle est posée dans toutes les organisations, généralement en dehors des réunions officielles. Un engagement écrit de la direction sur ce que l'IA ne servira pas à faire vaut mieux que dix diaporamas rassurants.
- Réécrire les procédures. Tant que le mode opératoire officiel décrit l'ancien geste, l'outil reste une option personnelle. L'usage ne s'installe qu'une fois intégré à la procédure.
6. Mesurer, y compris ce qui dérange
Trois familles d'indicateurs suffisent :
- Usage : part des utilisateurs actifs, fréquence, répartition par service. Agrégé et anonymisé — jamais de suivi individuel, qui détruit la confiance et vous expose juridiquement.
- Valeur : mesure avant/après sur une tâche type, chronométrée sur un échantillon. Imparfaite mais infiniment plus utile qu'une estimation déclarative.
- Qualité : taux d'erreur constaté, incidents, retours utilisateurs négatifs. Un système qui produit des réponses fausses non détectées coûte plus cher qu'il ne rapporte.
Publiez ces chiffres en interne, y compris les mauvais. Une organisation qui voit une direction annoncer l'arrêt d'un cas d'usage sur la base de données factuelles fait immédiatement confiance à la démarche.
7. Industrialiser ou arrêter
À l'issue du pilote, trois décisions sont possibles, et il faut avoir le courage des trois : généraliser, ajuster et reconduire une phase, ou arrêter.
L'industrialisation soulève des questions nouvelles : qui exploite l'outil au quotidien, comment sont gérés les incidents, comment les coûts d'usage sont suivis, comment on change de modèle sans tout reconstruire, comment le service est réversible si le fournisseur change ses conditions. Ces questions doivent être traitées avant la généralisation, pas après.
Les erreurs qui reviennent le plus souvent
- Commencer par acheter des licences pour tout le monde. Le taux d'usage réel s'effondre après six semaines et la démarche perd sa crédibilité.
- Confier le sujet à la seule DSI. C'est un sujet d'organisation du travail avant d'être un sujet technique.
- Chercher le cas d'usage spectaculaire. La valeur est presque toujours dans le back-office, pas dans la relation client.
- Traiter la conformité en fin de parcours. C'est la première cause de projets bloqués à la porte de la production.
- Ne rien mesurer. Sans chiffres, le projet ne survit pas au premier changement de priorité budgétaire.
Aucune de ces étapes ne demande une expertise technique rare. Elles demandent de la discipline, un peu de temps de direction, et l'acceptation qu'une partie des idées de départ sera abandonnée. C'est exactement ce que fait un accompagnement extérieur bien conduit : il tient l'ordre des étapes quand l'organisation, elle, a dix autres urgences.