Une stratégie IA qui survit au contact des opérations

Le premier signe qu’une stratégie IA va échouer apparaît souvent avant même le choix d’un modèle. Le comité de pilotage sait nommer plusieurs outils et des dizaines d’idées, mais personne ne sait nommer la décision opérationnelle qui doit s’améliorer, la personne qui en répond, ou la preuve qui justifierait de modifier le processus.

Une stratégie IA est un ensemble de choix portant sur le travail. Elle indique où l’IA peut créer de la valeur, quels usages sortent de l’appétence au risque, ce qui doit être prouvé, comment les risques seront maîtrisés et qui exploitera le résultat. Un catalogue technologique, un programme de formation ou une politique sur les modèles peuvent appuyer ces choix ; aucun ne les remplace.

Partir d’un travail qu’un responsable peut modifier

« Utiliser l’IA générative dans la relation client » est un thème. « Classer et orienter une catégorie définie de demandes clients, en conservant une voie d’escalade humaine » est un cas d’usage. La seconde formulation expose un déclencheur, un résultat, une exception et un propriétaire de processus. Elle peut être observée avant et après.

Cette approche par le travail rejoint la logique de l’approche européenne de l’intelligence artificielle. Un besoin clairement décrit rend possible la comparaison : IA contre règles, contre recherche, contre automatisation classique, ou contre une simple modification du processus.

Un premier cas d’usage crédible possède cinq propriétés :

• Un processus nommé : déclencheur, entrées, décisions, sorties et exceptions peuvent être décrits.
• Un responsable identifié : une personne a autorité pour modifier le processus et accepter le résultat opérationnel.
• Une base de référence observable : qualité, délai, reprise ou risque actuels peuvent être évalués sans inventer de précision.
• Un déploiement borné : le premier test peut être isolé d’un programme de transformation plus large.
• Une décision réversible : l’organisation peut étendre, réviser ou arrêter sans être devenue dépendante d’un système non éprouvé.

Les idées sans responsable devraient quitter le portefeuille actif. Les idées sans base de référence peuvent rester en exploration, mais ne sont pas prêtes pour une décision d’investissement. Une stratégie se renforce lorsqu’elle retire du travail autant qu’elle en ajoute.

Le comité social et économique n’est pas une formalité finale

En France, un point absent des modèles internationaux conditionne le calendrier. L’introduction d’un système susceptible d’affecter les conditions de travail, l’organisation ou le contrôle de l’activité des salariés relève de la consultation du comité social et économique. Un assistant qui journalise qui a traité quelle demande, en combien de temps, entre dans ce champ, même si personne n’a l’intention d’exploiter ces relevés.

En pratique, l’anticipation coûte moins cher que la régularisation. Les questions posées en instance — quelles restitutions sont possibles, qui peut les consulter, combien de temps les journaux sont conservés, l’usage individuel est-il évalué — sont celles auxquelles une configuration propre doit de toute façon répondre. Les traiter tôt permet de paramétrer le système une fois correctement plutôt que de le démonter après coup.

Rendre six choix explicites

1. Valeur

Formulez le résultat en langage opérationnel. L’objectif peut être un cycle plus court, une revue plus homogène, une capacité de service accrue, ou une tâche à forte charge informationnelle rendue plus simple. Séparez le résultat du mécanisme. « Déployer un assistant » décrit un mécanisme ; « aider un conseiller à retrouver la politique applicable et sa source pendant un appel » décrit un travail utile.

La valeur exige aussi une alternative de comparaison. Confrontez la voie IA à l’amélioration des données sources, à la simplification de la règle, à la modification d’une file d’attente ou à une automatisation déterministe. Si une intervention moins incertaine atteint le résultat, elle constitue souvent le meilleur choix stratégique.

2. Destination et limites

Rédigez la destination du système comme elle figurerait dans la documentation technique. Le règlement (UE) 2024/1689 construit presque tout son régime sur elle : la destination détermine la classification, les obligations et l’étendue de l’évaluation. Une organisation incapable de la décrire en une phrase ne pourra pas déterminer sa classification.

Les limites comptent autant que le périmètre. Quelles données sont exclues, quelles décisions le système ne prend pas, quelles catégories d’utilisateurs il ne sert pas : ce sont ces éléments qui détermineront plus tard si un incident était prévu ou constitue une surprise.

3. Preuve

Décidez à l’avance de ce qui vaudra preuve et de qui l’acceptera. Une démonstration n’est pas une preuve. Un jeu d’évaluation construit sur vos documents, votre terminologie et vos cas limites en est une. Le seuil se fixe avant le test, pas après.

Les fonctions Govern, Map, Measure et Manage du NIST AI Risk Management Framework fournissent ici une structure utilisable, même si le cadre est volontaire. Il sépare le pilotage du risque de sa mesure — précisément la distinction que la plupart des présentations internes escamotent.

4. Contrôle

Les contrôles se calibrent sur les conséquences, pas sur la technologie. Un système qui trie des propositions pour un utilisateur interne exige moins qu’un système qui affecte l’accès d’un client à un service. Dès lors que des données personnelles sont traitées, le règlement général sur la protection des données et les fiches pratiques IA de la CNIL s’appliquent sans changement.

5. Architecture et acquisition

Le choix entre produit sur étagère, plateforme configurée et développement propre est stratégique, car il détermine quelles obligations vous conservez. Le déployeur d’un système à haut risque a ses propres obligations ; un contrat ne les transfère pas au fournisseur. Vérifiez avant signature qui doit la surveillance, le contrôle humain et la conservation des journaux.

6. Responsabilité opérationnelle

Chaque système déployé a besoin d’une personne qui répond non du projet mais de l’exploitation : qui surveille la dégradation, qui approuve un changement de modèle, qui peut l’arrêter et dans quel délai. Si la réponse est « l’équipe data », la réponse est personne.

Gérer un portefeuille, pas une liste d’idées

Une liste d’idées grossit ; un portefeuille s’équilibre. Il est utile de répartir les propositions en trois groupes : usages à faible incertitude et valeur claire, qui peuvent passer directement en pilote ; usages à forte valeur et forte incertitude, qui exigent une exploration avant investissement ; et usages que l’organisation choisit délibérément de ne pas poursuivre. Le troisième groupe manque à la plupart des stratégies, et c’est celui qui donne aux dirigeants quelque chose à défendre.

Le Bureau de l’IA de l’Union européenne publie des lignes directrices qui évoluent. Le portefeuille a besoin d’un rythme de revue qui capte ces évolutions plutôt que de les découvrir lors d’un contrôle.

Utiliser des jalons capables d’arrêter le travail

Un jalon qui n’arrête jamais rien est une formalité. Pour fonctionner, il lui faut trois éléments : un critère fixé avant le test, une preuve recueillie par quelqu’un sans intérêt au résultat, et une option réelle de ne pas poursuivre. Consignez les trois. La documentation stratégique la plus utile en deuxième année est la trace expliquant pourquoi un usage a été arrêté.

Le bac à sable réglementaire est une option datée

Au 2 août 2026, chaque État membre doit disposer d’un bac à sable réglementaire national opérationnel pour l’IA. Pour les petites et moyennes entreprises, l’accès est gratuit, avec accès prioritaire et modèles de documents standardisés fournis par le Bureau de l’IA.

La valeur ne réside pas dans l’économie de frais mais dans l’accès au régulateur avant le déploiement. Une organisation qui a discuté la classification de son usage en amont aborde tout contrôle ultérieur dans une position différente. Pour un usage à la frontière entre haut risque et risque limité, c’est le moyen le moins coûteux de réduire l’incertitude. La contrainte est la capacité : les autorités démarrent avec de petites équipes et l’accès sera vraisemblablement disputé.

Ce que la direction doit pouvoir consulter

La direction n’a pas besoin d’une liste de modèles. Elle a besoin de quatre choses : quels usages sont en exploitation et qui en répond ; lesquels déclenchent des obligations réglementaires et sur quel fondement ; ce qui a été prouvé et avec quelle preuve ; et ce qui a été arrêté et pourquoi. Si ce rapport ne peut être produit en une journée, la stratégie n’est pas encore opérationnelle.

Les travaux du Comité européen de la protection des données sur la transparence constituent un repère utile pour ce qui doit être explicable à l’extérieur, et pas seulement en interne.

Ce que cette approche ne peut pas faire

Ce cadre ne prédit pas quel usage fonctionnera. Il ne remplace pas l’évaluation technique et ne rend pas certain un résultat incertain. Il ne règle pas non plus la question des compétences : une organisation sans personnes capables de juger si un résultat est correct déploiera lentement, quelle que soit la stratégie. Ce que le cadre apporte, c’est de rendre les choix visibles et réversibles, afin que les erreurs coûtent moins.

Si vous construisez une stratégie IA et souhaitez que le portefeuille résiste à l’examen opérationnel comme réglementaire, commencez par l’évaluation des cas d’usage et des risques.

Cet article est une adaptation de l’original anglais. En cas de divergence, la version anglaise fait foi.