Ni trop, ni trop peu : classifier et architecturer vos projets IA : partie 3

Dans les deux premiers articles, j'ai posé le cadre culturel et le cycle de vie de mon socle. Mais une fois qu'on a dit "il faut expérimenter", on se heurte très vite à une réalité technique : toutes les IA ne se valent pas.

Le piège classique que j'observe, c'est l'uniformité. Soit on traite un simple assistant de rédaction avec la même lourdeur administrative qu'un système critique (et on tue l'innovation), soit on laisse un agent autonome accéder au CRM sans surveillance (et on court au désastre).

Pour sortir de cette impasse, j'ai élaboré une "boussole" décisionnelle qui repose sur deux piliers : une typologie claire des architectures et une matrice de criticité dynamique.

L'UX d'abord, la tech ensuite

Ma conviction est qu'une architecture technique n'a de sens que si elle sert une expérience utilisateur (UX). L'IA sans UX n'est qu'un moteur posé au sol sans carrosserie : puissant, mais inutilisable.

J'ai donc classifié les implémentations en quatre typologies qui guident le passage du PoC à la production :

L'Assistant Simple (Type 1) : C'est du "Q&A" direct. Pas de mémoire long terme, pas d'accès aux outils. C'est typiquement l'aide à la rédaction d'emails. Ici, le risque est faible, l'architecture est légère (une simple API).
L'Assistant Augmenté (Type 2) : C'est le fameux RAG (Retrieval-Augmented Generation). L'assistant a accès à une base de connaissance interne. La complexité augmente : il faut gérer la fraîcheur des données et les droits d'accès.
L'Agent avec Tools (Type 3) : On change de dimension. Le LLM peut agir (envoyer un mail, interroger une API, réserver une salle). Ici, l'architecture doit inclure des mécanismes de validation et de "human-in-the-loop".
Le Flux Automatisé (Type 4) : C'est de l'orchestration pure (Code + LLM). L'IA est une brique dans un processus métier complexe (ex: analyse automatique de conformité documentaire). La complexité est maximale, la criticité aussi.

Cette grille permet de parler le même langage entre les équipes métier et les équipes techniques.

La matrice de criticité : pour gouverner juste

Une fois le type d'IA identifié, comment décider du niveau de contrôle ? Je refuse la bureaucratie par défaut. J'ai donc construit une Matrice de Criticité à deux dimensions pour calibrer la gouvernance.

Les deux axes sont simples :

L'Impact métier : Est-ce pour un usage individuel (faible) ou cela touche-t-il des processus critiques/clients (élevé) ?
La Sensibilité des données : Travaille-t-on sur de la donnée publique ou des secrets industriels/données personnelles ?

Le croisement de ces axes me donne 4 quadrants de gouvernance :

Quadrant A (Faible Impact / Donnée Publique) : C'est la zone de liberté. Une simple charte suffit. On laisse faire.
Quadrant B & C (Mixte) : Gouvernance modérée. Le Studio IA effectue une revue, on vérifie l'architecture (RAG sécurisé), mais on ne bloque pas.
Quadrant D (Impact Critique / Donnée Sensible) : C'est la zone "Rouge". Ici, je demande une validation formelle : revue d'architecture, tests de sécurité, validation juridique. C'est lourd, mais c'est justifié.

Cette matrice permet d'allouer les ressources de sécurité là où elles sont vraiment nécessaires, plutôt que de s'épuiser à surveiller des sujets triviaux.

Le système nerveux : la triple vigie

Enfin, j'ai voulu intégrer une sécurité contre l'aveuglement. Une classification n'est jamais définitive. Un projet anodin peut devenir critique s'il est soudainement adopté par toute l'entreprise.

Pour capter ces signaux, j'ai imaginé un "Triple Circuit de Vigie" :

Opérationnel (le ticket) : La remontée classique de bugs techniques.
Stratégique interne (l'usage) : J'analyse les logs (anonymisés) et les retours utilisateurs. Si l'usage explose (+20%), un "trigger" automatique demande une réévaluation de la criticité.
Stratégique externe (le radar) : Une veille continue sur la régulation (AI Act) et la tech. Si un modèle devient obsolète ou une faille est découverte, on réagit.

Conclusion

Ce socle architectural et décisionnel n'est pas là pour faire joli sur un slide. C'est un outil de terrain pour permettre aux développeurs et aux métiers de savoir quoi construire et comment le sécuriser.

Cependant, tout cela a un coût. Mettre en place un Studio, des sandboxes, des vigies... Est-ce réservé aux géants de la Tech ? Comment s'assurer que l'investissement rapporte vraiment ? C'est ce que j'aborderai dans le dernier article de cette série : "Au-delà du hype : pilotage, rentabilité et impact sociétal".