Comment construire une stratégie IA pour votre organisation

La plupart des documents que l’on appelle « la stratégie IA » se révèlent, à l’examen, être une liste de pilotes avec une diapo de vision attachée. Ils répondent rarement aux questions qui décident vraiment si l’IA devient une capacité organisationnelle ou un cycle récurrent de pilotes décevants : à quel point l’organisation est prête à être ambitieuse, ce qu’il faudrait construire pour y arriver, comment elle compte trancher les choix build vs buy qui reviennent chaque mois, et où le travail IA s’inscrit dans le modèle opératoire quand cinq équipes l’utilisent différemment.

Une vraie stratégie IA est le document qui tient le portefeuille ensemble. Elle dit au processus de sélection des cas d’usage quelles idées comptent le plus, au processus de gouvernance quels contrôles doivent passer à l’échelle avec le travail, et au processus de préparation quels filtres doivent être construits une fois plutôt que réinventés à chaque déploiement. Sans elle, chaque nouveau projet IA est essentiellement un coup unique, et l’organisation ne capitalise jamais d’un projet sur l’autre.

Cinq questions, tranchées par écrit et au bon niveau hiérarchique, séparent une stratégie d’une présentation. Sauter l’une d’entre elles est ce qui produit le prochain cycle de pilotes décevants.

La première est l’ambition : quel type d’organisation IA l’équipe dirigeante a l’intention d’être dans trois ans. Trois options honnêtes sont sur la table, et elles ne sont pas interchangeables. Assister : l’IA aide les rôles existants à faire leur travail existant plus vite (rédaction, résumé, recherche). Automatiser : l’IA prend en charge des workflows courants de bout en bout, avec des humains sur exception. Transformer : l’IA fait partie de la manière dont l’organisation crée de la valeur, avec de nouveaux produits, de nouveaux modèles de prix ou de nouveaux modèles opératoires qui n’existaient pas avant. Chaque palier coûte un ordre de grandeur de plus que celui d’en dessous, requiert une capacité très différente, et pose une question de gouvernance très différente. Faire semblant que les trois sont la même cible est l’origine la plus courante d’une stratégie qui échoue.

La deuxième est l’écart de capacité : ce que l’organisation a aujourd’hui face à ce que l’ambition retenue exige réellement. Qualité de la donnée, accessibilité de la donnée, profondeur d’ingénierie, MLOps, conduite du changement, et capacité à faire tourner une vraie équipe produit sont les écarts les plus courants. La stratégie qui liste des cas d’usage souhaités sans chiffrer honnêtement l’écart de capacité en dessous est une liste de souhaits, pas un plan.

La troisième est le build vs buy, posé au niveau de la stratégie plutôt qu’au cas par cas. Pour quelles catégories de travail IA l’organisation est-elle à l’aise de dépendre entièrement d’un fournisseur (API tierce, modèle tiers, flux de données tiers). Pour quelles catégories est-ce suffisamment stratégique pour investir dans du fine-tuning, des pipelines de récupération ou de l’infrastructure interne. La mauvaise réponse, c’est de laisser cette question à celui qui livre en premier ; ce que vous obtenez, c’est un verrouillage fournisseur silencieux à travers le portefeuille.

La quatrième est le modèle opératoire : où le travail IA vit dans l’organisation. Une équipe IA centrale qui détient le delivery. Des ingénieurs IA embarqués dans les business units. Un petit centre d’excellence qui appuie des équipes fédérées. Un hybride qui combine plusieurs. Chaque modèle convient à des formes d’organisation différentes, et chacun a des modes d’échec prévisibles si on le force sur un contexte qui ne lui correspond pas.

La cinquième est le talent : quels rôles recruter, quels rôles requalifier, quels rôles sourcer à l’extérieur, et quels rôles laisser intentionnellement en attente jusqu’à ce que le travail les justifie. La plupart des organisations sur-recrutent des data scientists et sous-investissent dans les rôles produit, ML engineering et conduite du changement, qui décident pourtant si le travail du data scientist atteindra un jour un utilisateur.

La décision la plus lourde de conséquences dans la stratégie est le palier d’ambition, parce que tout le reste se cale autour de lui.

Assister est le palier le moins cher et le moins risqué. Outils d’aide à la rédaction pour le commercial, résumé pour le juridique, complétion de code pour l’ingénierie. L’investissement va surtout dans les licences, la formation et une couche légère de gouvernance. Les retours sont réels mais bornés, et la stratégie n’a besoin de tenir que tant que les outils sous-jacents restent les meilleurs du marché. C’est le bon palier de départ pour la plupart des organisations de taille moyenne.

Automatiser est nettement plus cher et plus lent. L’automatisation de bout en bout exige une donnée amont fiable, un propriétaire opérationnel volontaire, un vrai jeu de validation et un chemin de repli. Cela demande aussi un programme de conduite du changement côté collaborateurs, parce que l’automatisation redéfinit les rôles. Les stratégies qui promettent de l’automatisation mais la financent comme s’il s’agissait d’assistance sont la raison pour laquelle tant de « transformations IA » s’enlisent au premier incident.

Transformer est rare et sérieux. C’est ce qui se passe quand l’IA change la manière dont l’organisation gagne de l’argent ou délivre sa mission, pas la manière dont ses collaborateurs existants font leur travail existant. Les stratégies de palier transformation ont besoin d’une propriété au plus haut niveau, de capital pluriannuel, et de la volonté de repenser produits, prix ou modèles opératoires. Ce n’est pas un positionnement marketing, c’est un engagement stratégique, et la plupart des organisations gagnent à choisir explicitement assister ou automatiser pour le moment, et à revisiter transformer plus tard, quand les fondations seront réelles.

La réponse honnête pour la plupart des organisations est « assister sur les douze prochains mois, automatiser à deux endroits précis d’ici dix-huit mois, transformer pas encore ». L’écrire, et dire non au reste, est plus stratégique qu’une présentation d’ambition de quarante diapositives.

Build vs buy au niveau de la stratégie n’est pas la même conversation que build vs buy sur un déploiement précis. C’est la conversation sur les catégories de capacité IA pour lesquelles l’organisation accepte de dépendre du marché, et celles pour lesquelles elle accepte d’investir pour les posséder.

Une bonne manière de tracer la ligne est la distance au cœur. Les capacités éloignées de ce qui rend l’organisation distincte (rédaction générale, résumé générique, complétion de code standard) sont presque toujours mieux achetées. Les capacités proches du cœur (le modèle qui valorise vos actifs spécifiques, le système qui route vos décisions opérationnelles spécifiques, l’assistant entraîné sur votre savoir institutionnel) valent souvent l’investissement dans la propriété, même à un coût plus élevé, parce qu’elles encodent quelque chose que l’organisation ne veut pas qu’un fournisseur puisse lui retirer.

Le modèle opératoire est ce qui rend ces décisions reproductibles. Une équipe IA centrale qui détient le delivery convient aux organisations avec un petit nombre de cas d’usage à fort enjeu. Un modèle fédéré avec un centre d’excellence qui appuie convient aux organisations avec de nombreuses business units distinctes, chacune avec ses propres cas d’usage. Un modèle purement embarqué (des ingénieurs IA dans chaque équipe, pas de fonction centrale) est rapide mais produit systématiquement des architectures fragmentées et une prolifération de fournisseurs. La bonne réponse dépend de la forme de l’organisation, et la mauvaise réponse, c’est de copier le modèle d’une entreprise qui ne ressemble en rien à la vôtre.

L’erreur de séquencement la plus courante dans les stratégies IA, c’est de partir des cas d’usage et de laisser la capacité suivre. Le schéma a l’air productif (les pilotes sortent vite, les dirigeants restent engagés), et il produit des résultats systématiquement décevants à douze mois, parce que chaque pilote re-découvre les mêmes écarts de capacité et repaye le coût de les résoudre isolément.

Un séquencement plus solide place les vagues de capacité d’abord, puis fait passer les vagues de cas d’usage par-dessus. Vague un, fondations : accessibilité de la donnée, un petit ensemble approuvé de modèles fournisseurs avec des contrats appropriés, un processus basique de gouvernance et d’incident, et une petite équipe d’appui. Vague deux, profondeur là où la stratégie en a besoin : pipelines de récupération, jeux de validation qui passent à l’échelle, MLOps, et une évaluation honnête des rôles dans lesquels l’organisation va investir. Vague trois, le portefeuille de cas d’usage à l’échelle, en s’appuyant sur des capacités que l’organisation possède réellement maintenant, plutôt que des capacités qu’elle continue d’espérer voir apparaître.

C’est aussi là que la stratégie IA rejoint la discipline plus large de transformation de l’organisation. Les capacités sont des décisions de gouvernance, de séquencement et de modèle opératoire à part entière, et elles ne deviennent pas plus faciles la troisième fois que le même écart est redécouvert.

Une stratégie IA n’est pas une liste de pilotes, une présentation d’ambition, ou une architecture de référence influencée par les fournisseurs. C’est le document qui décide quel type d’organisation IA vous comptez être dans trois ans, ce que vous êtes prêts à construire pour y arriver, et ce que vous choisissez explicitement de ne pas faire. Les organisations qui obtiennent une valeur mesurable de l’IA ne sont pas celles avec le plus de pilotes, ce sont celles dont la stratégie est suffisamment précise pour qu’on puisse réellement être en désaccord avec elle.

Le contexte plus large, dont la manière dont la stratégie se relie à la gouvernance, à la préparation, à la sélection des cas d’usage et au modèle opératoire, est rassemblé dans le cluster stratégie IA et automatisation. Et lorsque la question passe de « il nous faut une stratégie IA » à « nous en avons une et il nous faut quelqu’un pour la traduire en un portefeuille qui livre et en une capacité qui se cumule », c’est exactement ce sur quoi mon accompagnement gestion de projet et stratégie digitale est construit.