|

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!
|
|