To think, or to obey, that is the question

Je ne me lasse pas du spectacle de l’intelligence à l’œuvre dans notre monde contemporain. Sans cesse renouvelé. Toujours plus profond.

Aujourd’hui (et depuis quelques années), ce sont les méthodes suivies par certains êtres humains dans certaines entreprises qui m’émerveillent.

Plantons le décor : la grande entreprise, le service informatique, et la communication entre les parties prenantes. Si on est en France dans une logique de projet un peu ancienne, les 2 parties qui doivent coopérer en vue de produire une solution informatique se nomment, comme dans les grands projets de BTP, « maîtrise d’ouvrage » (MOA) et « maîtrise d’œuvre » (MOE). Si on est dans une logique de projet plus récente et plus « mondiale », les rôles se nomment par exemple « product owners » (PO) et « developers » (les « Dévs. »). Le principe est commun :

  • une ou plusieurs personnes représentent le besoin du client, de son métier, sans avoir forcément une connaissance de l’informatique
  • et plusieurs personnes avec des compétences techniques importantes, mais pas forcément de connaissance du besoin du client ou des métiers vont construire et délivrer une solution informatique répondant à ces besoins.

Et il faut donc que tous ces gens bien différents parviennent à travailler ensemble efficacement, et donc à communiquer correctement. La MOA ou les POs doivent formuler des demandes claires auxquelles la MOE ou l’équipe de développement pourra répondre de façon aussi efficace (et rapide) que possible. La qualité de la solution fournie, ainsi que ses coûts de fabrication et de maintenance, et évidemment les délais de réalisation, sont de plus en plus une clé de la réussite de l’entreprise, tant les solutions informatiques impactent et conditionnent les diverses activités de l’entreprise. La bonne communication dans les projets informatique est une des clés de la réussite de nombreuses entreprises.

Et dans notre société telle qu’elle est organisée, la bonne communication entre collègues n’est pas chose acquise. C’est même souvent une quête plus incertaine que celle de Don Quichotte.

 

Des méthodes pour exprimer correctement une demande ?

Pour y aider, des méthodes simples ont été peu à peu formalisées pour permettre à la MOA ou aux POs de transmettre un message clair, cohérent et complet à la MOE ou aux Dévs. C’est en particulier lorsqu’on arrive à des demandes assez précises et concrètes que la qualité de la communication est déterminante pour la réussite des équipes. En informatique, on parle alors de « Scénarios« , de « User stories » (XP, Scrum…), de « Cas d’utilisation » (UML…), ou simplement de « Stories » (Scrum, SAFe…) pour désigner ces actions simples que les utilisateurs veulent pouvoir réaliser grâce à la solution, les objectifs simples qui souhaitent atteindre.

Jetons un œil à ces méthodes. Leur point commun est que la demande doit pouvoir être résumée en une seule proposition, composée toujours des mêmes parties, et de proposer en conséquences des rubriques standards pour structurer l’énoncé de la demande. L’idée est que si chaque rubrique est dûment complétée, la demande sera intelligible et donc pourra trouver rapidement réponse adéquate. Voici quelques exemples de formulation rencontrés :

  1. As a …, I want …, so that
    = En tant que …, je veux …, afin de…
    est une formulation pour décrire l’ensemble du scénario (le rôle, l’action souhaité, la raison, l’objectif final)
  2. Given – When – Then
    = Étant donné – Quand – Alors
    est une formulation utilisée normalement pour préciser les critères d’acceptation de la solution, mais l’analogie avec les rubriques précédentes est importante ; elle permet de mettre en évidence la situation de départ, le contexte, puis l’action, l’évènement, le déclencheur, et enfin le résultat, l’issue, le changement

Voici donc 2 ensembles de concepts simples, cohérents, qui semblent aisés à utiliser et qui vont donc pouvoir améliorer à peu de frais la communication entre les acteurs du projet informatique. On ne peut éviter le parallèle avec la méthode quintilienne du QQOQCCP (celle que suivait le chef d’armée romain Quintilien pour donner des ordres clairs et précis à ses subordonnés). C’est simple, c’est facile, ça ne peut que marcher !

Notons que, aussi simples que soient ces formules, elles ne sont pas évidentes : demandez à 10 personnes d’en décrire la logique, de préciser ce que l’on met derrière chacun des 3 termes clés, et vous aurez 10 explications différentes, pas seulement par les mots employés, mais par le sens, la logique. Et donc utiliser l’une ou l’autre de ces formulations ne dispense pas de discuter et de réfléchir ensemble à leur utilisation, au contraire : on ne peut utiliser correctement ces méthodes 1) qu’après avoir d’abord établi un certain consensus sur ce que l’on attend dans chacune des rubriques, et 2) qu’à la condition d’évaluer ensuite les demandes pour s’assurer qu’elles répondent bien à la logique souhaitée, et surtout qu’elles apportent bien une meilleure communication, meilleure compréhension, meilleure coordination et donc meilleurs résultats. Sinon, nous sommes dans la position d’un enseignant qui croit qu’un écolier a tout compris simplement parce qu’il a suivi 5 minutes de cours théorique, et se désintéressant des résultats réels au cours des travaux pratiques, sous prétexte que lui, enseignant, a fait tout qui était nécessaire pour que ça marche. Et ça l’arrange bien, cet enseignant, de ne pas avoir à assurer le suivi de ses bonnes paroles dans les actions de ses élèves. C’est du travail en moins, et cela évite de se confronter aux résultats de son enseignement, et à l’élève perdu se demandant pourquoi ça ne marche pas.

Est-ce que ça marche ? Parfois oui, parfois non, ça dépend. Et plus on a affaire à un certain type d’entreprise, moins ça dépend, plus on peut parier que ces petits systèmes n’amélioreront en rien on presque rien la qualité de la communication.

Comment mieux le démontrer que de prendre des exemples concrets de mise en pratique de ces jeux de concepts ? Voilà quelques exemples, transposés pour ne pas donner une idée précise de l’entreprise ou du projet, mais fidèles à l’esprit (ou à son absence). Et croyez-moi, dans certains projets, il est bien plus difficile de trouver des demandes correctes que des demandes comme celles qui suivent. En l’occurrence, pour cet article, je n’ai que l’embarras du choix, et cela ne me réjouit nullement de pouvoir démontrer aussi facilement ce que je pense.

Forcer une forme carrée à entrer dans un trou rond,
pratique courante en informatique (et ailleurs, bien sûr)

Voici quelques exemples pour aider à comprendre :

 

Exemple 1

En tant qu’administrateur de [données] ,
Je souhaite que dans le catalogue ne soit affichées que les « bonnes » informations
Afin de respecter la demande des gens du marketing.

Analyse du « en tant que »

Le rédacteur de la carte pense à son propre rôle ou à celui du représentant métier qui a lui exprimé la demande. Mais ça ne suffit pas, ce n’est pas l’objectif : ici, dans une société où on prétend que le client, l’utilisateur final est la priorité, celui-ci est tout simplement oublié, on pense à l’administrateur qui saisit et vérifie les données du catalogue, et pas à la multitude de vrais utilisateurs, internautes, clients, qui vont consulter le catalogue en ligne et apprécierons d’y trouver les « bonnes » informations ! Si on ne pense qu’à l’équipe informatique ou à celle qui gère les données du catalogue de l’entreprise et qu’on occulte les vrais utilisateurs de ce catalogue, ceux pour lesquels précisément on le met en place, alors on est déjà hors sujet, l’objectif n’est pas le bon.

Analyse du « je souhaite »

Exprimé ainsi, merci, je croyais que l’objectif était d’afficher les mauvaises données, celles qui n’étaient pas pertinentes, me voilà rassuré. C’est là précisément qu’on attend du contenu et on ne trouve qu’un truisme. Avec même pas une note pour dire « voir à tel endroit la définition de ce qu’est une bonne information ». C’est là que le sens de la synthèse doit se manifester : arriver à dire quelque chose de consistant, d’informatif, en quelques mots, en une phase. Quitte bien sûr à renvoyer le détail à un autre paragraphe, voire à une documentation quelque part ailleurs (document joint, page wiki…).

On ne retire de cette partie de l’énoncé que le fait que cela concerne le choix d’affichage des informations dans le catalogue. C’est trop vague.

Analyse du « afin de »

Respecter la demande ? Ben oui, c’est ce pourquoi on fait une carte, un ticket, une demande JIRA. On est ici simplement en train de définir la fonction générale d’une demande JIRA, cela n’apporte strictement rien. On sait juste que la demande vient du service marketing. Et là on peut appliquer la même critique que pour le « en tant que » : et l’utilisateur final dans tout cela ? Celui pour lequel on conçoit le catalogue, celui qui va le consulter, y faire des recherches, des comparaisons, passer à la commande ? Là encore, occulté, il n’est pas dans la demande. On a l’impression que certains employés de l’entreprise, les informaticiens ont pour but de faire plaisir à d’autres employés de l’entreprise : les administrateurs de données et les gens du marketing. C’est un champ de vision un peu étroit.

 

Exemple 2

Étant donné que pour la gestion des [données] à venir un nouveau formulaire va devoir être créé
Quand ce dit formulaire sera à saisir certain champs seront sous forme de menu déroulant avec des valeurs à sélectionner
Alors il faut créer trois nouveaux référentiels internes dont voici les détails…

Ici on a à la fois une utilisation incorrecte des rubriques, et un choix inadapté de formulation.

  • Le « étant donné » doit faire référence à une réalité, un contexte, quelque chose qui existe, en fonction de quoi il faut faire quelque chose : ici, la rubrique est utilisée pour l’exact contraire, spécifier ce qui va arriver en dernier, une fois que tout sera en place
  • Le « quand » doit être précis pour spécifier un évènement, une action qui doit provoquer un changement, déclencher un traitement, démarrer un processus, aboutir à un résultat…
  • Le « alors » spécifie alors le changement provoqué, le traitement lancé, le processus démarré, le résultat souhaité suite à l’évènement ou l’action du « quand » : on se doute bien que ce n’est pas quand l’utilisateur arrive dans le formulaire qu’il faut créer 3 référentiels
  • C’est pitoyable : un employé plein de bonne volonté et pas forcément idiot tente de respecter les consignes qui lui sont données, il tente de se servir du modèle en vigueur, mais jamais il n’a appris ni à l’école ni dans l’entreprise, qu’un outil n’est qu’un outil, qu’il participe à une action intelligente, et que la première intelligence consiste à choisir l’outil en fonction de ce que l’on a à faire. Ici, nous avons le spectacle de quelqu’un qui tente de manger sa soupe aux vermicelles au moyen d’un couteau. Mais rien à faire : dans de nombreuses entreprises, dans de nombreux services, dans de nombreuses équipes, l’obéissance à l’autorité est plus forte, bien plus forte, que l’intelligence. Et chacun tente de manger son bouillon-vermicelles avec son couteau, en se demandant tout de même de temps en temps pourquoi ça n’avance pas comme prévu.

Au final, l’utilisation forcée de ce « given-when-then » finit par exprimer un lien cause-effet qui est exactement l’inverse de la réalité : l’énoncé (un peu mis en ordre) dit « il faut créer des tables parce que dans l’interface utilisateur on a besoin pour la saisie de listes de valeurs », alors que c’est l’inverse : parce que les champs doivent être renseignés avec des valeurs précises contenues dans des tables communes à plusieurs applications que l’interface ne doit permettre la saisie que par listes de choix, doit éviter que l’utilisateur indique autre chose que les valeurs possibles et répertoriées.

 

Exemple 3

En tant qu‘administrateur de [données]
je souhaite accéder à une table contenant les …
afin de pouvoir y insérer les valeurs pour XYZ

Ici, on peut certes commenter de même le contenu des 3 rubriques. Par exemple :

  • il n’y a pas une table de données, mais 17 ! Juste un détail…
  • il est indiquer « insérer », mais « mettre à jour » et « supprimer » ont été oubliés, or en matière de gestion des données, ces 2 dernières actions de modification et suppression ont une grande importance, elles peuvent rendre tout un système informatique inopérant
  • ce qui est souhaité n’est pas d’accéder à une table : on est en train de confondre la fin et le moyen, ce qui est souhaité, c’est de pouvoir saisir des données, autrement dit ce qu’il est indiqué dans la rubrique suivante, le « afin de »
  • et donc le « afin de » reste à définir : pourquoi a-t-on besoin de ces données dans ces tables ? à qui et à quoi vont servir ces données ?
  • les valeurs saisies ne sont pas « pour XYZ », mais « venant de l’application XYZ », on ne travaille pas pour une autre application nommée XYZ, mais on en récupère les données, ce qui est complètement différent.

Comme quoi on peut remplir toutes les cases et arriver à une carte fausse, incomplète et incompréhensible.

Mais là n’est pas l’essentiel. L’essentiel, c’est l’inadéquation de la solution par rapport au problème. Le problème, c’est de créer une table pour stocker certaines données. Ensuite on s’occupera de qui accède à cette table, comment et pour faire quoi, mais l’objectif de la demande est clair, ou devrait l’être : il faut d’abord créer une table. Dans la terminologie actuelle, cette demande porte sur un « enabler », un travail technique qui n’est pas demandé, mais doit être fait d’abord, car il rend possible la fonctionnalité demandée par l’utilisateur. Un peu comme le client qui veut une maison de demande pas que le terrain soit viabilisé : la viabilisation est un travail technique qui va permettre ensuite de construire la maison voulue par le client.

Dans le projet où cette demande a été faite, c’est d’autant moins normal qu’un modèle précis a été rédigé puis diffusé pour décrire correctement les demandes de création de tables et… éviter ce genre de formulation et de problème.

Donc malgré l’inadéquation patente d’un modèle, malgré l’existence d’un modèle adapté, on en arrive à une demande inexploitable. Dans ce cas, heureusement, quelques critères d’acceptation ont été spécifiés qui entrent un peu dans le concret, et des pièces techniques jointes pour apporter tous les détails des tables à créer. Par contre, ces documents joints n’avaient pas été vérifiés pour être sûr qu’ils étaient complets, à jour et conformes aux nouvelles normes informatiques. Donc nouveaux problèmes.

Choisir le bon outil selon le problème.
Pendant des millions d’années, ça a été une condition de survie.
Aujourd’hui, c’est carrément un luxe…

 

Cerise sur le gateau…

Lorsque il m’est arrivé de rédiger des demandes, je me suis fait retoqué… Bien sûr que ma rédaction n’était pas parfaite. Mais jamais on ne m’a fait un retour du style « Je ne comprends pas ce que tu écris », « Il me manque le pourquoi », « Ce n’est pas assez concret »… Le verdict tombait, implacable : ma demande n’est pas formulée de façon conforme !

Comme quoi, à force de prendre les employés pour des enfants, ils finissent par agir comme tels. Le moyen devient l’objectif à réaliser, l’outil devient le but à atteindre. Le chef a dit qu’il fallait faire comme ça.

 

Utiliser notre intelligence ou suivre une recette de cuisine ?

Les essais de communication en entreprise ressemblent par trop aux efforts de ces élèves qui n’ont pas compris la logique mathématique et se contentent d’appliquer scrupuleusement la règle de calcul du résultat qu’ils ont appris par cœur ou copié sur leur antisèche. La différence est ici qu’il ne s’agit pas de mathématique, mais d’une action simple et quotidienne ne demandant pas d’aptitude particulière et ne reposant que sur des qualités que tout le monde ou presque a déjà. Autrement dit, si nous ne communiquons pas bien, ce n’est pas parce que nous ne pouvons pas, c’est parce que nous ne voulons pas, parce que nous trouvons plus confortable d’obéir plutôt que de réfléchir, de suivre servilement les injonctions de l’encadrement ou des experts plutôt que de nous interroger nous-mêmes, d’accepter de changer, de vouloir progresser. Ainsi, si ça ne marche pas, nous pourrons dire : « Nous avons scrupuleusement fait tout ce qui était demandé, ce n’est pas de notre faute. Nous avons suivi toutes les recommandations, rempli toutes les cases, nous ne comprenons pas !« 

Désolé, c’est de notre faute. Nous sommes tous responsables des communications que nous établissons avec notre environnement, et donc des communications de travail en entreprise. Nous avons tous un rôle important à jouer pour accroître ou maintenir la qualité de nos communications. Et pour cela nous devons bien sûr comprendre ce qui se passe, et comme ce n’est pas compliqué, il suffit de regarder pour comprendre. Il faut juste avoir un peu de courage pour accepter l’idée de pouvoir se tromper et d’avoir à s’améliorer.

Une communication réussie, c’est lorsque ce que veut faire passer l’émetteur se retrouve dans ce que le destinataire a effectivement reçu et retenu, lorsque à l’issue de la communication, les protagonistes partagent une vision suffisamment proche du même sujet. Ou que, si chacun reste avec sa vision des choses, qu’il ait au moins compris la vision des autres.

Apporter au destinataire une information qu’il a déjà, qui est partagée, consensuelle, voire évidente, cela ne sert à rien, et même en informatique, cela confine à la non-information. Bien communiquer, c’est apporter juste les informations utiles.

Ce n’est pas davantage apporter trop d’information, soit par détail excessif, soit par non pertinence des informations. Tout dire est une des plus sûres façons de mal communiquer.

S’exprimer avec notre propre terminologie, sur ce qui nous semble important, en occultant tout ce qui nous semble évident ou facile, forçant ainsi l’interlocuteur à s’adapter et à se mettre au niveau, est une autre façon communément répandue d’échouer tout en rejetant le problème sur notre interlocteur. Un bon communiquant est quelqu’un qui sait adapter son langage et la structure du contenu à l’interlocuteur, à sa situation, son langage, son expérience, ses connaissances, ses motivations. Eh oui, communiquer, c’est s’intéresser à l’autre, faire preuve d’un peu d’empathie, s’adapter à lui. C’est une habileté humaine qui implique de nombreuses qualités. Ce n’est pas une recette de cuisine, ce n’est pas une phrase toute faite avec des cases vides à remplir.

Une première évidence est qu’on ne communique pas de la même façon avec des gens qui débarquent sur un sujet et n’y connaissent rien qu’avec des gens qui sont sur un sujet depuis plusieurs mois (voire années) et connaissent le contexte, le métier, l’application… En gros, communiquer, c’est s’adapter 1) au contenu que l’on communique et 2) à l’interlocuteur auquel on communique. Si on se contente d’appliquer un modèle figé de communication, on est certain dans une majorité de cas de se planter. Appliquer de façon rigide une méthode immuable n’a jamais apporté une quelconque souplesse pour s’adapter, une quelconque agilité.

Enfin, si un des éléments essentiels d’une demande est de préciser le besoin, de « donner du sens » pour reprendre l’expression à la mode, pour qui et pourquoi on fait les choses, alors il faut une capacité à regarder plus loin que le bout de son nez. Pour lui ? Mais lui, il travaille pour qui au final ? Pour cela ? Mais pourquoi doit-on arriver à cela ? Le pourquoi est la question la plus complexe de toutes. L’analyse des causes et des effets demande toute notre clairvoyance, toute notre intelligence. Imposer une formulation de phrase pour donner du sens ne garantit pas que l’utilisateur de cette formulation donnera du sens. Dans la plupart des cas, le sens, c’est ce que je parvenais à reconstruire malgré la formulation (ou malgré son utilisation bancale).

Ces « méthodes », ces formules d’énoncé, ces rubriques nous fournissent une trame possible, sûrement pas une trame nécessaire, et presque jamais la trame bien adaptée au besoin spécifique de communication, sur une demande particulière, dans un contexte particulier d’entreprise, dans une équipe particulière.

A l’inverse, quelqu’un qui sait communiquer saura sans respecter un quelconque rituel de formulation, apporter dans un écrit tous les éléments nécessaires.

Je vais même plus loin : standardiser la formulation nuit souvent à la qualité de l’énoncé, aboutit à des énoncés tellement stéréotypés que leur lecture devient rébarbative. Encore plus loin : la compréhension d’un énoncé implique une activité mentale importante et complexe de la part du lecteur, et uniformiser trop, si cela facilite la lecture, diminue la quantité d’activité mentale nécessaire pour assimiler l’information. Et donc cela amoindrit la profondeur de compréhension. Qui plus est, le lecteur aura plus de chances d’adopter le point de vue du rédacteur, alors qu’une formulation plus libre par l’émetteur va forcer le lecteur à rassembler et recoller les informations à sa façon, à reformuler. Nous savons très bien que la reformulation permet à la fois permet de mieux comprendre et de s’assurer que l’on s’est bien compris. Elle permet surtout de faire apparaître des problèmes (contenu insuffisant, divergence de points de vue…) qui détectés à l’avance, évitent de partir dans une mauvaise direction.

Enfin, un rapide coup d’œil sur ces méthodes permet de suite d’en limiter le périmètre : « en tant que… », « je… ». On est clairement en train de proposer un modèle pour une « User story », une histoire utilisateur, un scénario avec un acteur humain, avec une interface utilisateur, un écran. Et plus on s’éloigne de ce cas de figure, moins le modèle sera pertinent.

 

Des bonnes pratiques ?

Ces méthodes sont elles inutiles ? Non, elles peuvent aider des rédacteurs un peu brouillons ou novices à rédiger de façon plus cohérente et complète, sans oublier un point essentiel.

Ces méthodes gagnent bien évidemment, selon la nature du projet, à être étoffées par des modèles de demande créés par les équipes du projet ou au moins choisis et adaptés par elles. Là on peut arriver à améliorer pas mal la qualité des demandes formulées. A condition bien sûr que ces modèles de rédaction soient bien compris et utilisés (on le sait très rapidement). Sinon, c’est que le problème est ailleurs.

Si un problème récurrent de communication se pose à l’occasion des demandes, alors il ne faut pas espérer trouver une solution avec ces recettes de cuisine, avec ces formulations imposées. Si un problème de communication est récurrent, c’est qu’il y a des obstacles à la communication : ces obstacles peuvent être dans l’organisation de l’entreprise, la hiérarchie, la gestion des projets, la culture (mentalité) d’entreprise, voire parfois liés à des personnes en position stratégique dans le projet (MOA, POs, chefs de projet…). Dans ce cas, utiliser ces règles de formulations de demandes, et même d’autres règles « maisons », avec des modèles personnalisés et adaptés à chaque type de demande, cela revient à appliquer un emplâtre sur une jambe de bois. Le problème est ailleurs, et la première difficulté est déjà de l’admettre. Une fois admis, la seconde est la résistance au changement, la rigidité du fonctionnement actuel et des habitudes acquises. C’est sûr que c’est plus facile d’adopter des règles de formulation qui ne remettent rien ni personne en question !

 

Cela va-t-il évoluer ?

L’urgence économique croissant, les bouleversements sociaux se multipliant, je ne crois pas beaucoup à un assainissement des conditions de travail qui permettraient aux employés de mieux penser et de mieux communiquer. Je pense même que nous sommes en train de rajouter plusieurs obstacles sur les voies déjà tortueuses de la communication :

  1. Le principal obstacle est sûrement la délocalisation du travail, et donc le décalage de plus en plus important de la langue.
  2. Non négligeable est aussi la perturbation croissante du travail par les communications médiatiques, celles-ci venant d’ailleurs souvent de l’entreprise censée assurer des conditions de travail correctes. Dans ne nombreuses entreprises, la communication n’est plus d’ailleurs plus un moyen simple et quotidien, mais une organisation, une direction, qui finit pas exister pour elle-même et pour d’autres motifs qui n’ont rien à voir avec les bonnes conditions de travail.
  3. Quant à la croissance du chômage, des faux emplois ou emplois précaires, qui va de pair avec la dégradation des relations hiérarchiques (pour des raisons de sécurité, on acceptera aujourd’hui d’un chef ce qu’on n’aurait pas accepté il y a même seulement 20 ans), je doute que cela assure la sérénité nécessaire à la fois pour penser et communiquer clairement : pour communiquer correctement, il faut oser le feedback, oser dire qu’on n’a pas compris ou qu’on n’est pas d’accord, oser demander de discuter ou de clarifier.

Je me souviens aussi de toutes ces années passées à l’Université à corriger les copies, et à constater, sur une période de presque 15 ans, la baisse du niveau d’orthographe et de grammaire, et donc la nécessité d’être en 1990 très indulgent vis-à-vis de devoirs écrits par des étudiants universitaires qui à l’école secondaire de 1975 auraient tout simplement apporté un zéro à leur auteur. Et ce ne sont pas les smartphones et les réseaux sociaux qui inverseront la tendance.

La seule chose dont je suis certain, c’est qu’une mauvaise communication n’aboutit jamais à quelque chose de viable, de durable, qu’il s’agisse de la relation de couple, de l’éducation, ou du travail en entreprise. Cette communication qui ne marche pas à un coût, et ce coût est énorme. Enorme, mais jamais comptabilisé, puisqu’il échappe non seulement aux outils utilisés en entreprise pour évaluer les coûts, et même à la conscience de ceux qui utilisent ces outils. La communication efficace est ce qui permet par exemple à des insectes grégaires de se comporter tous ensemble de façon extrêmement efficace alors que l’intelligence de chaque individu est des plus limitée : les grandes entreprises actuelles s’extasient d’ailleurs sur ce qu’elles baptisent l’ « intelligence collective ». Elles aimeraient bien que leurs employés soient organisés de façon aussi efficace. Mais pour le moment, les êtres humains sont loin, peut-être même de plus en plus loin des prouesses de ces insectes.

Les méthodes n’y font rien. Tant qu’elles sont mises en œuvre de façon hiérarchique et dogmatique, non seulement elles n’apportent aucune amélioration réelle, mais elles contribuent à masquer les problèmes réels en apportant l’illusion d’avoir fait quelque chose. Les vrais problèmes n’étant pas traités, ils ne sont pas près d’être résolus, et peuvent donc prospérer. Nous ne pouvons qu’espérer en un sursaut des intelligences individuelles avant que le miroir aux alouettes de l’intelligence collective ne nous amène à la faillite.

 

Plaidoyer pour une intelligence collective

Et pourtant, moi qui écrit ces lignes, je suis profondément convaincu que l’intelligence collective est possible chez l’être humain, même si ses instincts les plus puissants l’en détournent souvent. Mais je ne suis pas de ces familles où l’on doit absolument défendre le pire salaud « parce qu’il est de la famille », ou de ces gauchistes qui se sentent tenus d’excuser le plus malhonnête d’entre eux « parce qu’il est de gauche, et que si des gens de gauche disent du mal d’autres gens de gauche… ». Je m’autorise à avoir les mains libres : quand le message est dévoyé et corrompu, ce n’est plus un bon message. Quand des méthodes sont ainsi mises en œuvre, à ce point vidées de leur intelligence pour devenir de simples contraintes hiérarchiques, alors on ne peut que gagner à s’en passer.

Oui, l’intelligence collective est possible. Et c’est même assez facile. Mais pas tant que nous de changeons pas radicalement nos habitudes, nos mentalités, nos organisations, et clé de voûte de tout cela, nos hiérarchies.

.

Soyez le premier à commenter

Poster un Commentaire

Votre adresse de messagerie ne sera pas publiée.


*