Résumé des points clés
Cet article porte sur le conflit de perception courant au sein du monde professionnel, où l'on affirme que « quelque chose n'est pas compliqué ». Il révèle les raisons pour lesquelles les managers et les exécutants ont des perceptions différentes d'une même tâche : les deux parties considèrent le problème à des niveaux d'abstraction différents. Les managers se concentrent sur des objectifs simplifiés (comme le « remboursement de l'utilisateur »), tandis que les exécutants doivent faire face à de nombreuses anomalies, contraintes et risques réels (tels que des temps d'attente réseau pendant le remboursement, des soumissions répétées, des changements de permissions, etc.). L'article analyse également les facteurs linguistiques, organisationnels et de ressources à l'origine de ce conflit et souligne que ces biais de perception seront encore plus marqués à l'ère de l'IA, insistant sur l'importance de reconnaître la complexité réelle.
I. Différence de perspective : les leaders voient une « ligne », les exécutants face à un « réseau »
Pour les leaders, la tâche se résume à un processus idéal simplifié : par exemple, « l'utilisateur soumet une demande de remboursement → le système vérifie → le remboursement est effectué ». Mais pour les exécutants, il faut gérer tous les imprévus qui surviennent en dehors de ce processus : que faire si l'utilisateur n'a pas rempli toutes les informations ? Que se passe-t-il si le réseau s'interrompt et que l'argent n'est pas retiré ? Comment réessayer si l'interface de paiement tiers ne répond pas ? Un même utilisateur peut-il demander un remboursement deux fois, entraînant un double paiement ? Ces questions représentent un véritable « réseau » qui occupe 80 % du temps des exécutants.
Par exemple, créer une démo de remboursement peut prendre seulement trois jours (à condition que le système fonctionne correctement une première fois), mais sa mise en œuvre dans un environnement réel nécessite un mois entier, car il faut prendre en compte tous les cas possibles pour s'assurer que le système ne connaîtra pas d'erreurs.
II. Le « tour de passe-passe » du langage : le langage naturel cache la complexité
Lorsque nous exprimons nos besoins en utilisant le langage naturel, nous omettons de nombreux détails. Par exemple, dire « ajoutez une fonction de remboursement automatique » semble simple, mais cela implique de nombreuses questions : qui a l'autorité pour déclencher un remboursement automatique ? À partir de quel montant le remboursement doit-il être vérifié manuellement ? Un remboursement peut-il avoir lieu même si l'utilisateur a déjà reçu la marchandise ? Comment informer l'utilisateur en cas d'échec du remboursement ? Ces détails ne sont pas intentionnellement cachés par les exécutants ; ils existent simplement et n'ont pas été mentionnés.
C'est comme lorsque vous demandez « apportez-moi un café » : vous ne précisez pas si vous voulez du café glacé ou chaud, s'il faut ajouter du sucre, ou quelle boutique choisir. Les exécutants doivent obtenir toutes ces informations pour bien répondre à votre demande. Plus la description des besoins est concise, plus de détails les exécutants doivent compléter, ce qui explique pourquoi il y a souvent des désaccords entre eux : ceux qui formulent les demandes pensent que « vous êtes trop exigeant », tandis que les exécutants estiment que « vous n'avez pas été suffisamment clair ».
III. Le « filtre de compression » de l'organisation : plus on est haut dans la hiérarchie, moins on voit la complexité
Dans les grandes entreprises, les informations sont progressivement simplifiées : les employés de base gèrent chaque jour des problèmes (10 anomalies en moyenne), les responsables techniques les réduisent à trois risques, et les managers de département à un seul problème. Pour le PDG, il ne reste peut-être que « le projet avance un peu lentement ». Cette compression est nécessaire (le PDG ne peut pas gérer chaque détail technique), mais elle peut amener les dirigeants à penser que « les problèmes n'existent pas vraiment ».
Par exemple, lorsque vous utilisez l'ascenseur, vous appuyez sur un bouton et vous arrivez au étage sans vous soucier du système de freinage, des capteurs ou des mesures de sécurité qui se trouvent derrière. Une équipe efficace gère ces complexités au niveau le plus bas, permettant aux dirigeants de penser que « tout fonctionne normalement ». Cependant, lorsque les personnes clés quittent l'entreprise, ils réalisent soudainement à quel point le système est en réalité complexe.
IV. Le jeu des ressources : dire que quelque chose n'est pas compliqué, c'est essayer de gagner du temps et de l'argent
Parfois, les dirigeants affirment que quelque chose n'est pas compliqué pour contrôler les ressources nécessaires (recrutement, budget, délais). Si l'on admet la complexité, il faut augmenter le personnel, allouer plus de fonds ou prolonger les délais. Cependant, les coûts cachés ne disparaissent pas ; ils sont simplement déplacés ailleurs. Par exemple, si le temps de test est réduit, des problèmes peuvent survenir après la mise en service du système, nécessitant des efforts supplémentaires pour les résoudre. Si la surveillance n'est pas adéquate, les pertes peuvent être plus importantes.
C'est comme lorsque vous faites des travaux de rénovation et que vous décidez d'omettre l'étanchéité pour économiser de l'argent : cela semble sans problème sur le moment, mais après six mois, les dégâts peuvent coûter dix fois plus cher à réparer.
V. De nouveaux pièges à l'ère de l'IA : « Facile à créer, difficile à rendre fiable »
L'IA rend la création rapide de prototypes très simple : ce qui prenait des semaines il y a quelques années peut maintenant être réalisé en quelques heures grâce à l'IA. Cela peut faire croire que tout le système est facile à utiliser, mais en réalité, l'IA ne résout que le problème de la « faisabilité ». Par exemple, si l'IA gère les commandes, elle sait comment les traiter, mais pas quelles commandes ne doivent pas être modifiées, ni comment corriger les erreurs ou gérer les problèmes avec d'autres systèmes.
Le danger est que l'IA exécute rapidement : un employé peut commettre 10 erreurs par jour, tandis qu'un algorithme IA en peut commettre 1000 en une minute, et cela peut affecter plusieurs systèmes à la fois. À l'ère de l'IA, il ne s'agit plus de savoir si quelque chose est possible, mais de savoir si les risques peuvent être maîtrisés (par exemple, quand l'IA doit s'arrêter, qui prendra en charge les conséquences des erreurs, et comment identifier les responsabilités).
Conclusion
Dire que « quelque chose n'est pas compliqué » n'est pas faux en soi, mais il faut comprendre que **ce qui est simple, c'est l'objectif ; ce qui est complexe, c'est la réalité ». La prochaine fois que vous entendrez cette phrase, ne vous emportez pas dans une dispute. Demandez-vous d'abord : « Voyons-nous la simplicité idéale ou la complexité cachée ? » Après tout, la maturité réelle ne consiste pas à nier la complexité, mais à transformer celle-ci en un système gérable.