Automatiser n’est pas forcément améliorer #3

Cet article fait partie d'une série dans laquelle je tente de poser les bonnes questions sur l'IA en tant qu'architecte.

Dans beaucoup de discussions autour de l’IA, une idée revient presque systématiquement : si un processus est lent, coûteux ou pénible, il faut l’automatiser.

En tant qu’architecte, j’ai appris à me méfier de l'équation :

automatisation = amélioration.

Elle est simple, mais elle peut masquer une réalité beaucoup plus complexe.

Ce qu’un processus raconte vraiment

Un processus métier n’existe jamais par hasard. Même lorsqu’il n'est pas optimal, il est le résultat :

• de contraintes historiques,

• de compromis organisationnels,

• de décisions parfois implicites.

On a vite fait de critiquer la situation à un instant T, se disant qu'on n'aurait jamais mis les choses en place de cette manière. Cependant, nombreux sont les facteurs expliquant l'implémentation actuelle.

C'est pourquoi, automatiser un processus sans le comprendre, ce n’est pas le simplifier. C’est figer ses hypothèses.

Et malheureusement, ces hypothèses sont rarement documentées.

Le piège de l’efficacité apparente

L’IA est très efficace pour automatiser de nombreuses tâches :

• décisions répétitives

• priorisations

• classifications

• recommandations

A priori, les bénéfices sont immédiats :

• moins d’intervention humaine

• temps de traitement réduits

• moins de risque d'erreur

Mais ce que l’on gagne en efficacité opérationnelle, on peut le perdre en capacité d’évolution/d'adaptation.

Lorsqu'on était dans le cas des automatismes “classiques”, on maîtrisait en générale l’ensemble des règles et des logiques mis en place.

Avec des automatismes basés sur l’IA, la situation est différente : le système établit des corrélations qui ne sont pas toujours explicitement formulées, ni entièrement compréhensibles a priori.

Ce n’est pas nécessairement un point faible, par contre c’est un changement majeur du point de vue architectural.

Et un processus automatisé “qui fonctionne” va très vite être considéré comme incontestable. Même lorsque les premiers effets de bord apparaîtront (exceptions non envisagées, logiques manquantes,...), rares sont les cas où l'on prendra le temps de revoir le processus.

Un exemple concret

Prenons un cas très courant.

Une équipe de support met en place une IA pour classer automatiquement les tickets entrants et définir leur routage.

L’objectif est clair : soulager les équipes en leur offrant une meilleure structuration de leur travail au quotidien.

Au début, tout va mieux. Les tickets simples sont traités rapidement. Les temps de réponse s’améliorent.

Mais au fil du temps, on se rend compte que les cas complexes ou à la marge sont mal classifiés. Ils ne rentrent pas bien dans les cas prévus.

Ce n’est pas tant que les règles soient incomplètes que le fait que le modèle a appris des corrélations statistiques qui fonctionnent très bien dans la majorité des cas (même si l'on ne sait pas toujours expliquer pourquoi).

Donc tant que la réalité reste proche des données d’apprentissage, le système semble pertinent. Dès qu’on s’en écarte, les limites apparaissent — souvent là où les enjeux sont les plus sensibles.

Avant, un humain détectait ces cas “bizarres”. Il prenait le temps de les requalifier et pouvait remonter le soucis aux équipes techniques afin d'adapter le modèle d'assignation.

Après automatisation, ces cas passent à la trappe - on est plus rapide, mais on devient aveugle à ces exceptions.

Ce que l’automatisation supprime vraiment

Il serait faux de dire que lorsqu'on automatise, on supprime également le jugement humain au sens strict.

En effet, pour mettre en place un automatisme :

• on établit des règles de base

• si nécessaire, certains compromis peuvent être figés dans le code

• et certaines exceptions peuvent être délibérément ignorées ou acceptées

Ce processus est défini et validé par des humains, du moins pour les cas d'automatisations classiques.

La différence avec l’IA, ce n’est donc pas l’absence de règles humaines, mais le fait que ces règles prennent la forme de corrélations statistiques, parfois impossibles à dérouler de manière linaires.

On ne sait plus toujours quelle logique précise a conduit à telle ou telle décision — seulement qu’elle est cohérente avec le modèle.

On supprime de par ce fait sa capacité à exercer un jugement au moment où la réalité diverge du modèle.

Seul un humain pourra faire preuve d'arbitrage lorsqu'il sentira que "quelque chose ne va pas" - prenant en même temps la décision de ne pas suivre la règle et de s'adapter à une situation qui sort des clous.

Ce qu'on supprime, c'est donc :

• une capacité de remise en question,

• une identification de manquement du système.

Pourtant, ce sont précisément ces zones-là qui permettent à un système de rester vivant, qui évoluera dans le temps.

L’architecte ne doit donc pas seulement se demander si un processus peut être automatisé, mais ce que ce processus permettait d’absorber comme complexité.

Automatiser, c’est faire un choix de conception

Du point de vue architectural, automatiser n’est jamais un acte neutre. C’est une décision de conception structurante.

Elle impacte :

• la responsabilité (qui corrige quand ça bug ?),

• la gouvernance (qui peut remettre le processus en question ?),

• la capacité d’évolution (comment on évolue quand le contexte change ?).

Le rôle spécifique de l’architecte

Face à un projet d’automatisation par l’IA, le rôle de l’architecte est de poser des questions inconfortables.

Par exemple :

• Quelles exceptions ce processus gérait-il implicitement ?

• Quelles décisions étaient prises “au cas par cas” ?

• Qu’est-ce qu’on accepte de perdre en flexibilité ?

Ces questions peuvent ralentir le projet mais comme souvent, elles évitent surtout de créer un système rigide, difficile à corriger, et déconnecté de la réalité du terrain.

Améliorer, ce n’est pas toujours automatiser

Améliorer un système peut parfois passer par :

• une clarification du besoin,

• une simplification du processus,

• une meilleure formation des équipes,

• ou une redéfinition des responsabilités.

L’IA peut être une excellente réponse. Mais seulement après avoir compris ce que l’on cherche réellement à améliorer.

Comme nous l'expliquions dans le premier article de la série, la technologie (automatisation) n’est qu’un moyen, et ne devrait jamais devenir un objectif.

Conclusion — Conseil aux Architectes

Avant d’automatiser un processus avec de l’IA, pose-toi cette question :

Quelles exceptions ce processus rendait visibles, et que l’automatisation va inévitablement masquer ?

Si tu n’as pas de réponse claire, alors l’automatisation risque de masquer les zones d’exception plutôt que de les traiter — et de figer le système dans un état où il ne peut plus évoluer.

Un bon architecte ne cherche pas à rendre les systèmes plus rapides à tout prix. Il cherche à préserver leur capacité à être maîtrisés, remis en question et ajustés face à des situations imprévues.

Et parfois, la meilleure amélioration consiste simplement à se laisser le temps de laisser ces exceptions émerger et être comprises.