les derniers
articles

Index &
Sommaire
 

Articles « Info » : management

 


DÉCOLLAGE !


Présentation du
site WEB AILES
 


Management :
Informaticien et Français... (1 / 3)
(ben, c'est pas gagné...)
Culture de l'implicite
[Management],
[PBaudry], [wdhb], [EAIeb], [PDrucker74]


    Bien connaître ceux que vous devrez manager et/ou ceux qui vous managent, c'est indispensable, afin de les rendre productifs (deuxième mission du management, après la performance économique de l'entreprise)
Or ce sont des informaticiens (ou au moins évoluant dans le milieu de l'informatique).
Et ce sont des français.
    Vous ne voyez pas comme l'ombre d'un problème, là ? Allez, je vous aide : Comment se caractérise l'informatique ? Par une origine avant tout anglo-saxonne, basée sur l'explicite. Et quelle est votre culture ? latine, française, basée sur l'implicite, le sous-entendu, le non-dit.
    Quelles sont les conséquences de ce mélange culturel forcé ?
    Ce qui suit se base largement sur les travaux de
[PBaudry], notamment sur son chapitre 5 :"L'Explicite". Ses conclusions sont replacées ici dans le contexte du milieu professionnel des ingénieurs en informatique, afin de mieux vous aider à en comprendre certaines pratiques... cette interprétation n'engage donc que moi (simple informaticien, cf. Avertissement !).
    Attention, les comparaisons permanentes entre les 2 cultures (américaine et française) ne visent pas à mettre en valeur l'une plus que l'autre, mais simplement à mieux comprendre notre culture et ses "implications" dans le domaine informatique.


 



Lisez-moi et
réagissez !



Écrivez à AILES !



Page suivante :
Informaticien & Français : vertical



Retour vers le sommaire Management
 
Implicite Français vs Explicite Américain
    Pour mieux comprendre à quel point notre culture se base sur un mode de fonctionnement implicite, [PBaudry] choisit la technique du contraste et met face-à-face la culture Française et Américaine.
    « La norme américaine est l'explicite. Le mot égale la chose. La carte égale le territoire. » [PBaudry]...
    Si vous êtes ingénieur informaticien, vous avez l'occasion de vérifier ce caractère explicite tous les jours... dans les documentations! (qui a dit : « de toute façon, moi je ne lis jamais les docs... » ? sisisi, vous devez bien vous y référer de temps en temps) : chaque point est détaillé, et l'application de ces points doit faire que le logiciel marche.
Une des rares fois où je suis tombé sur une omission dans une documentation d'un logiciel américain (qui ne mentionnait pas un partage de répertoire sous Unix, opération pourtant évidente que j'aurais dû/pu deviner tout seul), il m'a suffit de leur renvoyer un mail du genre : « Vous écrivez une doc, je suis la doc point par point et... ça ne marche pas. Ne croyez-vous pas qu'il manque quelque chose ? ». Leur réponse fut : « une demande d'évolution de la doc est en cours pour rajouter cette étape. ». Ils ne m'ont jamais dit : « ben évidemment qu'il faut le partager, c'te répertoire... pffff. »
    En France, au contraire, on a tendance à juger la personne - son intelligence surtout - à l'aune de ses questions. La mienne m'aurait implicitement placé dans la catégorie "truffe de base"!
    « En France, la norme est l'implicite, le mot y est différent de la chose, le signifié du parlant. Ce décalage entre ce qui est dit et ce qui est signifié laisse la place à l'allusion et à la référence historique partagée. Le Français ne fut pas pendant plusieurs siècles la langue des Cours d'Europe parce que ce serait la langue la plus précise, mais parce que c'est la langue qui permet d'être imprécis le plus précisément. » ([PBaudry])
Cela est possible grâce au contexte riche de la culture française : dès que l'on nous dit quelque chose, nous cherchons en permanence à décoder ce que notre interlocuteur nous dit vraiment
: Ainsi, demandez à votre développeur français si son programme tourne. Vous répond-t-il que "oui"... et vous cherchez de suite à savoir s'il marche vraiment (c.à.d. si les tests unitaires et les tests de non-régression ont été passés avec succès, ou bien si le "ça marche" recouvre simplement une compilation et une première exécution sans plantage apparent). Pour un développeur américain, qui connaît son process de développement (compilation, tests, exécution), un programme qui marche... marche. Point.
(cf. également les illustrations sur le sens du mot bug)
   ... Bien sûr, ce n'est pas en lisant la documentation informatique en français que l'on peut s'en rendre compte. La majorité est traduite de l'américain(!). Mais si l'on se penche sur des ouvrages techniques écrits par des français, comme [EAIeb], on trouvera des phrases comme "mettre à disposition un site sur lequel il sera possible d'assembler totalement sa voiture et de la recevoir dans un délai de 3 semaines!" (sous-entendu, le délai normal est bien plus long, mais cela n'est pas précisé dans ce livre...), ou encore "une plate-forme [de compagnie aérienne] générera à terme quelque 30 milliards de dollars par an!" (sous-entendu, il s'agit d'un volume énorme... mais on a aucune idée du volume habituel d'une compagnie aérienne...). Toujours dans [EAIeb], on peut lire l'expression bien française "notre chère administration", qui renvoie à notre vécu face à ces multiples institutions.
    Seulement voilà, trop expliciter les choses est vu en France comme prendre son interlocuteur (à savoir, en informatique, un technicien de haut niveau, tout de même ;) ) pour un benêt...

    Cet aspect "explicite vs. implicite" a plusieurs conséquences :

Partage contre mutualisation

    « La place de l'explicite dans la culture américaine correspond à l'idée protestante que la collectivité - et, par voie de conséquence, les individus - ont plus à gagner qu'à perdre en mettant le plus d'informations possibles sur la place publique.
    À l'inverse, les Français se prémunissent contre une dissémination jugée excessive et potentiellement dangereuse des informations personnelles, par exemple grâce à la loi Informatique et Libertés.
    Les Américains voient ce qu'ils ont à gagner dans le partage, les Français voient ce qu'ils ont à perdre. » ([PBaudry])
    A lire cela, on peut se demander si Internet aurait pu se développer en France! Surtout du temps du protectorat Gaullien évoqué par le déjà-cité ingénieur de 30 ans de métier, avec le "Plan Calcul"!
   [PBaudry] cite l'exemple du "credit rating" qui permet de monitorer les crédits accordés, alors que cela est jugé en France comme une "intrusion intolérable" : « Les Français préfèrent une non-transparence qui, au nom de la protection de la liberté individuelle, crée de facto une mutalisation du coût du crédit, les bons et les mauvais payeurs étant au chaud dans le même sac. » ([PBaudry])
    J'ai l'impression que ce désir de "non-transparence" se retrouve rapidement chez tout informaticien (quelque soit sa nationalité)... Il me semble que le dernier système d'exploitation Microsoft qui cherchait des informations "un peu partout" sur l'ordinateur a reçu un accueil mitigé des 2 côtés de l'Atlantique, obligeant l'éditeur à revoir un minimum sa copie.
    À l'inverse, Internet, mais aussi les hackers (qui, rappelons-le ne sont pas forcément des pirates mais bien des personnes dont la culture est basée sur le partage de l'information, même - et surtout - lorsque cette information est difficile d'accès et/ou à comprendre !) rencontrent un succès grandissant en France, y diffusant une vraie envie de partager : les forums spécialisés - en français - en sont une illustration.

Binaire vs. imprécision
    « La culture américaine est binaire : une proposition y est vraie ou fausse. Le Français baigne avec aisance dans un océan d'incertitude qu'il contribue à entretenir. » ([PBaudry]). Cette rigueur binaire est idéale pour l'informatique. Les langages les plus récents - qui sont le plus utilisés dans l'industrie du logiciel (C++, Java, C#) - sont d'ailleurs tous basés sur un typage fort (typage statique déclaratif explicite) et tendent à imposer des normes informatiques construites sur ce modèle (de l'explicite). La notation de modélisation est également devenue explicite et commune : UML s'est imposé face à un Merise resté bien franco-français...
    L'imprécision française devient avérée dès qu'il s'agit de mettre en œuvre un standard : par exemple, une norme de programmation : chacun aime à coder comme il l'entend, et il faut vraiment qu'il y ait un audit pour que les standards soient respectés... En matière de programmation, la seule fois où j'ai vu une norme "à peu près" respectées fut celle où un programme automatique détectait et corrigeait en grande partie - automatiquement - les déviations par rapport à la norme!
    Il n'y a vraiment que dans les expressions marketing ("one of the very best", ...) où un peu d'imprécision se glisse dans les 2 cultures. Si vous rédigez une documentation technique, vous verrez que l'on vous demandera d'ôter systématiquement toute expression du style "sans doute le meilleur des" : la technique s'accommode mieux de faits que d'appréciations... on retrouve en revanche une approche plus binaire dans les publicités comparatives aux US, alors qu'elles sont interdites en France! Ainsi, les logiciels américains n'hésitent pas à mettre en avant leur "features grid" (grille de fonctionnalités) incluant une comparaison point par point avec leur concurrent.
    N'oublions pas, enfin, que "l'océan d'incertitude" constitue pour le Français une source de pouvoir qui lui permet d'étendre sa zone d'influence et ses prises de contrôles...

Simplicité - complexité
    « Le Français sera plus attiré par le complexe que par le simple. Une des forces de la culture américaine est de savoir créer de la valeur par la simplification du complexe. » ([PBaudry])
Un exemple classique se trouve dans nos études supérieures (math sup, math spé par exemple), où le niveau mathématique se veut complexe et différent de l'approche américaine (qui ne démontre pas les théorèmes, mais les utilise).
Mais cela a aussi un effet pervers en informatique : la grande mode de toutes les API actuelles est à l'encapsulation : tout protocole se trouve encapsulé par - au moins - une API dans un langage donné, comme JNDI qui encapsule LDAP, JMS qui encapsule les MOM... cela est bien et permet de simplifier la mise en œuvre de ces protocoles. Mais que font les informaticiens (en tout cas les Français que j'ai vu utiliser ces API) ? Ils encapsulent(!) à leur tour l'API qui encapsule le protocole... « c'est pour être indépendant face à toute évolution de l'API», prétendent-ils... 
« Pourquoi faire simple quand on peut faire compliqué ? »! (tiens ? mais cette dernière expression est la devise des Shadocks... une création française... pourquoi ne suis-je pas étonné...)

Mensonge vs... vérité
    « La norme américaine est de ne pas mentir. Cela ne signifie pas qu'il n'y a pas d'Américain menteurs, mais qu'il est considéré plus normal et plus souhaitable de dire la vérité même si cela déplait, que de mentir, même par "politesse". » ([PBaudry])
En clair, on peut mentir... mais juridiquement c'est durement sanctionné! Cela explique l'extraordinaire précision des termes employés dans les normes du W3C : si vous les lisez, vous verrez que des termes comme "shall", "must", "should", "could" sont explicités en début de texte, afin que ce que la norme décrit ne soit pas interprété dans le mauvais sens, prêtant le flanc à une présentation mensongère! (cf. également les illustrations sur le sens du mot bug)
Plus anecdotique, cela explique aussi pour le Français qui prend un vol pour les US se voit obligé de remplir un formulaire de douane qui lui demande : « Êtes-vous un terroriste ? »! Ce n'est pas tant dans l'espoir d'obtenir une réponse "vraie" que dans le but d'établir une pièce à charge si jamais vous avez répondu "non" mais que vous êtes pris en tant que terroriste : le fait d'avoir menti sera alors rajouté contre vous.
    Dans le même esprit, la norme US est de répondre à la question posée : on ne change pas de sujet, on ne répond pas par une autre question, donc la conversation apparaît plus plate, moins rythmée.
Là encore, le côté implicite et imprécis de la langue française nécessite constamment d'interpréter la réponse fournie, comme l'illustre cette humoristique traduction pour informaticien!
Mais cet esprit "répondre à la question" se trouve encore plus bafoué... dans les réunions! Les Français organisent des réunions en arrivant avec un ordre du jour, n'en discutent que de la moitié et rajoutent d'autres points! Les Américains suivront l'ordre du jour, établiront un compte-rendu indiquant clairement les décisions prises pour chaque point, qui est responsable de l'application de ces décisions, et pour quand doivent-elles être complétées! J'ai déjà retrouvé ce type de compte-rendu très formel et très complet sur des projets informatiques à la mentalité anglo-saxonne.
(Pour information, chez les Japonais, c'est encore différent : tout se discute avant ou après la réunion : celle-ci n'est que la formalisation d'un accord ou désaccord autour d'un ordre du jour. Leurs réunions sont donc courtes, et l'on y parle peu!)


Innovation
    [PDrucker74] décrit l'innovation comme la fourniture de satisfactions économiques différentes, qui procure des produits meilleurs et moins chers - nouveaux ou non, en tout cas différents -, dont le but est de créer un nouveau marché, parfois simplement en trouvant un nouvel usage à un ancien produit.
    Or, pour ([PBaudry]), « pour innover, il faut recombiner de façon nouvelle des éléments existants. Pour cela, il faut que les-dits éléments aient été préalablement identifiés, et donc détachés les uns des autres de façon sécable. Innover, c'est faire apparaître dans un contexte (background) un premier plan (foreground) qui n'existait pas avant cette innovation. »
    Cette démarche est plus naturelle dans une culture explicite! Mais en informatique, où l'on manipule des concepts explicites tout le temps, l'innovation se rencontre dans les 2 cultures : JBoss est l'exemple d'un produit "meilleur" et, à ce titre innovant, initié par un français.
    Le problème réside plutôt dans la nature de l'innovation en informatique : 
- d'un côté, les innovations répondent pour la plupart à des problématiques qui ont au moins 30 ans (la transaction, la sécurité, la communication asynchrone, etc...).
D'où le constat de cet ingénieur - français - de 30 ans de métier : « 30 ans que l'on fait la même chose » !
- de l'autre côté, la façon dont les informaticiens procèdent, leur process, reste désespérément inchangé, même si les récentes méthodologies de style "XP - Extrem Programming" et autres "méthodes agiles" viennent enfin secouer les esprits (attention, UML n'est pas un process, juste une notation, quant au RUP... ce "Unified Process" nécessite un gros travail d'adaptation, et reste bien trop lourd pour être appliqué "tel quel").
D'où la protestation de Laurent Bossavit : halte au culte du cargo.


Conclusion
    Ces quelques pointeurs peuvent vous aider à mieux comprendre les comportements de vos collègues / supérieurs et/ou subordonnés, ingénieurs en informatique et Français! Il ne s'agit pas de juger "l'autre culture" (ici américaine), mais de mieux nous cerner et, au final, de mieux travailler ensemble, ce qui permet de "maximiser notre performance"... (tout le but du management)
    Il ne faudrait pas voir ici une liste exhaustive des caractéristiques de notre culture : Pascal Baudry en met en lumière bien d'autre dans son ouvrage que je ne peux que vous recommander.
    Ainsi, d'autres aspects -détaillés par ([PBaudry]), seront abordés dans cette section management, en particulier l'aspect très "vertical" de notre culture - il suffit de considérer l'expression courante "La France d'en haut et la France d'en bas" -
Cf. Informaticien et Français ? - Verticalement - Dur!



               
 
Avertissement !
 
Décollage !  |  Présentation du site web "AILES"  | 
Infos générales  |  articles "Informatique"