Embedded weblog

Aller au contenu | Aller au menu | Aller à la recherche

lundi, juillet 9 2012

de la rhétorique méthodiste, de la complexité des choses et du miroir

Il fut un temps, il y a quatre ans, où j'écrivis un billet à propos de l'agilité et du développement logiciel. J'avais peur d'avoir dit des choses atroces sur lesquelles j'étais sans doute revenu dans mon propre ouvrage Linux embarqué : comprendre, développer, réussir, où je m'étends assez largement sur le management de projet. Mais que nenni : c'est bien de développement (et plus spécifiquement de XP) dont j'avais parlé sur le blog, alors que je parle de gestion de projet dans mon livre lorsque je fais l'éloge de l'Agile, et apporte bon nombre de nuances lorsqu'il s'agit de développement effectif (qui est d'ailleurs principalement de l'intégration, et non du codage). Tant mieux pour ma schizophrénie (déjà que je dois faire des Assemblées générales avec moi-même qui doit voter à l'unanimité, je ne peux pas me permettre d'embaucher une nouvelle personnalité multiple).

En gestion de projet informatique, il n'y a pas que l'Agile qui soit apparu sur le devant de la scène : il y a aussi le lean. Je me suis donc penché sur le sujet, il y a quelques temps. Et c'est très intéressant. Prenons donc un ouvrage écrit par la JMAC — apôtres/prophètes du lean (je choisis mon vocabulaire) —, très complet et synthétique à la fois. Une première chose frappe : ce n'est, a priori, pas du tout adapté à autre chose que la fabrication en usine — et à ce niveau, mieux vaut avoir une idée de comment ça fonctionne, une usine ; ou mieux, de savoir ce qu'est le travail ouvrier, et même si le consultant insiste sur le fait de devoir connaître intimement le métier (ont-ils [bien] lu Henry Mintzberg, eux aussi ?), je doute quelque peu que McKinsey, Bain ou plus modestement JMAC aillent embaucher des ouvriers comme consultants (ça fait penser aux fameux "stages ouvrier" d'école d'ingénieur... Et Marie-Antoinette fut bergère). Passons.

Nous touchons là un premier problème : la notion "d'industrie" appliquée au logiciel. C'est à mon avis un très gros écueil. Il y a, en France, un culte de l'industrie. À l'ENA, à l'X et encore plus dans le corps des Mines, on parle de l'Industrie comme d'un joyaux merveilleux. Peu importe la réalité (le débat économique est toujours ouvert, ce serait trop long à traiter, tout au plus peut-on s'amuser d'un Jean-Louis Beffa — La France doit choisir — qui vante le modèle industriel américain florissant en citant Microsoft et Facebook, après avoir dénigré les services qui ne génèrent que des CA peu élevés — en fait non, c'est plutôt agaçant), le fait est que pour séduire le politique, même le Syntec numérique, même le Conseil national du numérique doivent communiquer sur ce registre. "L'industrie du logiciel". C'est dangereux, parce que cela donne des billes à ceux qui n'ont toujours pas compris que le logiciel ne se "fabrique" pas sur une chaine de montage, et dénigrent l'essence artisanale du développement (malgré des indices comme le régime juridique applicable, je n'arrête pas de le répéter). On vend peut-être notre âme au diable.

Récemment, j'ai dû discuter de l'emploi du terme "usine" pour un ensemble d'équipes de développement matériel et logiciel (le problème de l'embarqué, aussi, est qu'il est à la frontière de deux mondes, mais qu'il vient avant tout du hardware industriel). Évidemment, celui-ci est employé de manière positive, mais sa réception par les équipes de développement était négative — travail à la chaine, sans valeur ajoutée propre, horaires inconfortables, manutention, les idées associées sont forcément péjoratives dans l'esprit du cadre. La question est alors de savoir si l'on peut remarketer pour faire passer le fond de la pensée, ou si l'acte de langage (conscient/inconscient, en tout cas en réception passive intégrée) est le plus fort. Mais au-delà de ça, la notion de "software factory", vieille notion vivotant et réapparaissant régulièrement, a déjà été discutée (de manière extensive en 1997 !), pour montrer l'inadéquation avec le développement logiciel en général, tandis qu'il s'agit plutôt là d'une confusion entre les différents métiers du logiciel (en l'occurrence, l'assemblage — assez utopique à un certain degré — de briques génériques pour créer un nouveau logiciel répondant à une attente d'un client ; plus généralement, je conviens que la TMA n'est pas vraiment de l'artisanat comme le développement "pur").

Ainsi en irait-il du lean en milieu logiciel ; la différence fondamentale est que le management est peu connu et considéré par les développeurs (c'est une tragédie, réellement), et qui n'ont donc pas d'a priori à son encontre. On aura compris, pour ce qui nous intéresse, que le lean ne doit pas être considéré dans ce qu'il met en place concrètement pour la fabrication (du moins dans ce qu'il préconise) mais dans les processus et dans son esprit — même si l'on peut chercher à adapter certaines idées d'optimisation de l'environnement de travail ou de tâches répétitives, quoique ces dernières correspondent plus à d'autres branches de l'informatique comme le réseau ou la DSI. Le "petit" problème, à ce niveau, est que si je prends l'évangile selon JMAC (oui, oui, je choisis toujours mon vocabulaire), ce qui va m'intéresser est... la préface. Pas beaucoup plus. C'est un peu gênant. Mais au moins, je suis tout à fait d'accord avec elle, c'est déjà ça. On peut tirer d'excellentes et pertinentes choses de ces préceptes généraux — la question étant "peut-on toujours appeler cela du lean ?".

Ce qui m'a dérangé, très profondément, dans la lecture du livre de la JMAC, est l'aspect prophétique de conversion. Mais cela ne m'a pas vraiment surpris : j'avais avalé du Pierre Legendre avant. Le discours est donc de type "techno-science-économie", totalement assumé, avec même des formules mathématiques complexes qui fournissent un indice en nombre de containers (?) que l'on ne sait pourtant pas interpréter, ou des diagrammes au format particulier, pour modéliser des actions, ou encore des techniques de mesures "intelligentes". Et toute une démonstration sur la nécessité de l'optimisation, du calcul, de l'agencement, de la performance, de la réflexion. Ce, sous l'égide du marché qui pousse toujours plus loin, plus haut, plus fort (on le rappelle d'ailleurs dans la préface, en ces temps de crise — ce n'est pas sans saveur puisque l'on fait référence, paradoxalement, aux années de disette du Japon où ce système a donc eu toutes les vertus...). Pour aller même encore plus loin (et c'est tout un sujet de tension), on y dit même de ne point rejeter l'Organisation scientifique du travail de Taylor, bien au contraire.

Mais l'avant-dernière phrase du livre fait tomber le masque : "Pour aboutir à une transformation lean, il faut y croire !". Quel médecin pourrait dire "si vous voulez que votre jambe cassée guérisse, il faut y croire !" ; quel physicien dirait "pour que la lumière se réfracte, il faut y croire !" ; quel chimiste dirait "pour que cette solution réagisse, il faut y croire !". On quitte bien le domaine de la science, du prédictible, de la causalité. Quel est la part d'effet placebo ? Je m'amuse, pour ma part, à relever que l'on entre dans le domaine de la foi, celle qui fait des miracles. Le miracle, c'est le changement, pour un monde meilleur, celui qui rend heureux, à la fois l'ouvrier "optimisé" et l'actionnaire (rassemblons-nous en rond et célébrons la fin de l'affrontement des classes).

L'autre indice, et celui-ci est absolument criant par le vide laissé, est la totale absence d'auto-critique. Rien. Tout se passe pour le mieux dans le meilleur des mondes. On pourrait au moins avoir des mises en garde : "attention, si vous ne faites pas correctement ceci, ça va mal se passer". Je ne me souviens que d'un seul passage de ce type, où l'on insiste sur l'attitude à adopter pour faire accepter à l'ouvrier de se faire mesurer par un chronomètre juste à côté de lui (ce moment m'a d'ailleurs fortement fait penser à Surveiller et punir... Le tout avec moult bonnes intentions déclarées, comme dans tout bon pavage). À un moment, on nous dit bien que c'est tout de même très japonais que tout cela, et qu'il faut faire attention à la culture locale (assez savoureux aussi, mais je risque de beaucoup m'étendre : en résumé, le Japon a avalé la culture occidentale qui lui a été imposée, et l'a remodelé en fonction de ses traditions ancestrales, pour un résultat qui fascine à présent ceux-là même qui avaient mené la conquête de la pensée). Je romps le suspense : la critique existe ! Ailleurs.

Lorsque j'ai dit "lean", une fois sur Twitter, j'ai eu une réaction de Pierre Denier (qui n'est pas le dernier des débarqués et qui n'est pas non plus un idéologue), de type "oulah !" ; j'ai demandé pourquoi : parce que ça a fait bien plus de mal que de bien. Benoitement, je demande : mais les préceptes ont-ils été bien suivis ? Aïe. Ça veut bien dire, au mieux du mieux, une chose : le lean peut être assez ambigu pour générer exactement l'inverse de ce qui est attendu (du moins pour l'ouvrier, mais comme je suis marxiste par intermittence, le capitaliste en souffrira forcément par ricochet). Ce n'est pas rien ! Allez, pire encore, en images : ce reportage de France 3 (dont le titre assez idéologique trahit un certain parti-pris, c'est dommage : La mise à mort du travail), qui montre la mise en place du lean dans une usine, et au final... on a remplacé un mal par un autre mal (au lieu de parcourir des kilomètres, les ouvriers piétinent, ils ont des cadences beaucoup plus fortes qu'ils ont du mal à assumer sur le long terme, ils ressentent des douleurs, etc.).

Pour en revenir à la médecine (et à la philosophie), on tient là un pharmakon : tout médicament est un poison en puissance, tout dépend du savant dosage. Et ça, c'est le meilleur des cas (le pire : ça n'a jamais marché et tout n'est qu'écran de fumée — on me dira "Toyota", je répondrai que l'on a vu quelques soucis de leur côté qui n'étaient pas des moindres, ces dernières années). Voilà au moins un avertissement majeur qui aurait mérité de figurer dans notre cantique ! Mais la seule parade semble être d'opposer qu'un échec suivant la mise en place du lean est que l'on a mal compris, tout comme on a mal compris la bible quand les catholiques se sont laissés aller à des pratiques regrettables. Pirouette.

Où est l'homme dans cet étalage méthodologique qui dit ne pas en être un (mais suffisamment pour avoir son vocabulaire, ses techniques, ses livres, ses apôtres, ses écoles... et même un nom !), dans cette théorie détaillée qui nous assure que tout est dans la pratique ? Nous sommes ici aux confins du management tel que Pierre Legendre le dissèque dans Dominium Mundi : l'Empire du management (mais aussi dans La Fabrique de l'Homme occidental, avec une brève référence aux études du toyotisme, comme succession aux études théologiques). Le lean est un aboutissement car il prétend remettre l'homme au centre, dans une rhétorique élaborée. Le reportage suscité (La mise à mort du travail) est extrêmement acerbe : ce n'est que tromperie de la pire espèce ; au moins, le taylorisme était plus clair sur l'utilisation de l'homme comme force de travail (bref : la lutte des classes et l'exploitation du travailleur, au moins c'est clair, on n'essaie pas de nous enfumer). Est-ce réellement le cas ? La question est pertinente, mais j'ai bien peur que le débat soit saboté à la base pour qu'il n'y ait l'espoir d'une quelconque réponse.

Prenons un autre exemple, encore plus criant. Le Six Sigma est aussi un sujet très à la mode. J'ai donc sélectionné un ouvrage (la librairie de l'ESCP est une merveille et son libraire absolument remarquable), paru à l'AFNOR (je ne savais pas qu'ils avaient une maison d'édition interne, c'est en tout cas amusant de relever un nombre très important de coquilles dans un livre qui parle de qualité et d'erreurs inférieures à 3,4 par millions d'opportunités... Ils donnent en tout cas des formations "certifiantes") : Six Sigmas, la force du changement en période de crise. On commence par nous dire qu'il n'y a pas de miracle ni de solution miraculeuse. Mais tout à coup, on assiste à un déferlement de calculs, d'indicateurs chiffrés, de références sociologiques trop vite interprétées (dans le meilleur des cas, car il y a aussi des conclusions importantes tirées à partir de mémoires de MBA lambdas...), le tout dans un magma rhétorique entièrement dynamisé dans le sens de l'auteur, qui fait un usage très abusif du mot "donc". Qualité, excellence et changement forment le triptyque d’une idéologie masquée par un vernis scientifico-technique.

L'excellence est également un thème très fort dans le lean, qui recoupe beaucoup celui de la qualité, aussi central dans le lean (ce n'est pas pour rien que les deux ont pu se marier pour donner le "Lean Six Sigma"), qualité directement associée à la satisfaction client, ce qui est un grand raccourci. Je vous propose de regarder le trailer de mon ami Hugo Jacomet pour le Corthay Excellence Run, où l'on parle d'excellence et de qualité. Il s'agit d'artisanat, y compris dans les voitures. Ici, pas d'effet de manche : il s'agit véritablement de purs métiers manuels d'expertise, autour d'arts décoratifs profondément ancrés (dans l'histoire, la tradition, la culture), au service de la beauté et d'un fonctionnement parfait, par les meilleurs artisans. Le lean et le Six Sigma oublient quelque chose : tout est affaire de compromis. La population, dans sa consommation de masse (je ne parle pas de comportements particuliers, tels que le mien) n'est pas prête au luxe, déjà pour une question de moyens (mais cela mériterait de s'attarder sur les problématiques économiques, et notamment de la pression vers le bas des prix des biens qui ont poussé à la mondialisation, pour à présent des taux de chômage élevés dans les professions peu qualifiées — et je ne suis pas un protectionniste !), mais surtout parce que ce n'est pas ce qu'elle désire. Ce que le client veut, de nos jours, c'est la nouveauté, ce qui implique des couts peu élevés et des changements réguliers. Dans leur immense majorité, les hommes préfèrent acheter régulièrement des chaussures de mauvaise qualité pour 100€ plutôt que de s'offrir une paire de Corthay à 1000€ qui durera 50 ans (je ne parle pas des femmes : c'est tellement maladif qu'une offre de chaussures de qualité n'existe même pas !). Cela recoupe exactement le mythe de l'obsolescence programmée (dès qu'il y a une théorie du complot, on peut être certain de faire fausse route).

Le Six Sigma, qui fait donc ses gorges chaudes de la qualité ultime sans parler du cout que cela engendre et de la pertinence au regard du cout répercuté sur le client final, est donc complètement à côté de la plaque. Cela n'empêche pas de trouver de bonnes et même de très bonnes idées dans le livre et la méthode, mais il faut savoir faire la part des choses, et avoir les idées claires pour cela. Or, lorsqu'on y voit clair, on voit aussi tous les autres trous noirs sophistes de la pensée. Le moins grave (et le plus partagé !) est de parler de culture d'entreprise comme si cela était quelque chose d'évident, alors même qu'après recherches, j'ai trouvé que la sociologie s'était penché sur le sujet, à bien des reprises, sans rien trouver de probant. Le plus étrange est cette folie du changement, paré de toutes les vertus, où l'aspiration naturelle de l'homme à la stabilité est péjorativement qualifiée de "frein", en tout point similaire à la réformite de l'État français (ce n'est plus un moyen mais une fin en soi) ; où l'on a envie de rappeler, à force, qu'une révolution, c'est tourner sur soi-même ("Se vogliamo che tutto rimanga come è, bisogna che tutto cambi !", comme on dit). Mais ce qui interpelle le plus est encore une fois du côté de l'homme. Où est-il ? Page 19, accrochez vos ceintures (noires ou vertes) : "On s'aperçoit donc que l'organisation est également un système constitué d'hommes et de femmes, sans lesquels aucun résultat ne pourra être obtenu". No comment.

L'homme est folklorisé. Le management moderne a compris qu'il faut un théâtre et des rites à l'homme, sans comprendre que c'est une inscription qui donne du sens à sa vie. L'usage de la théâtralisation artificielle se voit par exemple dans une longue séquence du séminaire du groupe Otis dans L' Empire du Management. À présent, c'est le quotidien qui est visé, au-delà d'un évènement annuel unique s'apparentant à la grand-messe et au pèlerinage. Pour le Six Sigma, il s'agit des yellow belt, green belt, black belt, champion et autres rôles attribués : il s'agit d'une réduction de la vie à un jeu de rôle codifié, rationalisé, prédictible. C'est une nouvelle mode, que l'on retrouve peu ou prou un peu partout (le Scrum master, par exemple). Page 73, l'auteur répond aux oppositions sur ce vocabulaire étrange(r) : c'est un moyen efficace (selon quelle mesure scientifique ?) pour changer le référentiel et donc la pensée des individus, afin de les rendre malléables en vue du changement. La révolution culturelle ou le rêve soviétique, en somme (l'entreprise comme organisation totale tendrait-elle à devenir totalitaire, dans cette optique ?). Notons au passage que le vocabulaire n'était qu'une part de critique acerbe de James Téboul (INSEAD, décidément !), et en fait la moins pire...

Enfin, une dernière remarque pour la route : d'où vient le chiffre 6 de Six Sigma (Sigma comme l'écart-type), dans cet univers scientifisé ? Après tout, tout le monde reconnaît que 3 ou 4 sigma est déjà pas mal à atteindre. Cinq serait extraordinaire. Pire encore : tout dépend des indicateurs utilisés ! (Et dès lors que l'on s'attaque à des processus de services, autant dire que ça peut être tout et n'importe quoi...) La réponse est avancée page 44 : "Saint-Augustin d'Hippone (354-430) clamait dans son livre La Cité de Dieu que le nombre 'sénaire exprime la perfection de l'ouvrage divin'. Il ajoutait que le 'le chiffre 6 est parmi tous les nombres, le premier qui se compose de ses parties, je veux dire du sixième, du tiers et de la moitié de lui-même ; en effet le sixième de six est un, le tiers est deux et la moitié est trois ; or un, deux et trois font six'. On perçoit dès lors l'objectif de l'approche. Cette perception est corroborée par la lettre grecque qui suit." (Note : j'ai modifié les erreurs de typo au passage). C'est délicieux ! Bien plus qu'une vulgaire couverture recyclant la chapelle sixtine (coïncidence ?).

Au final, quel sens à donner à tout cela ? Le livre d'Emmanuel Pascart sur Six Sigma est sorti en 2009, ce qui nous permet de prendre un peu de recul. Parmi les entreprises citées en exemple (et parfois américanisées à tort, comme Nokia !), on peut se rendre compte que la malédiction du Prix de l'excellence a encore frappé (ce livre mythique est d'ailleurs cité tel quel dans notre ouvrage, tout comme on voit cette néo-bible déposée à un moment sur un bureau dans La mise à mort du travail — serait-ce de là que vient d'ailleurs ce fétichisme de l'excellence ?). Pour rappel, dans l'ouvrage de McKinsey, on citait un certain nombre d'entreprises modèles, telle qu'Atari ; la plupart d'entre elles ont coulé dans les quatre ans qui ont suivi la parution du livre (ce qui fait beaucoup rire les sociologues et économistes). Eh bien, pour Six Sigma, nous avons : Nokia, Polaroid (qui a aussi fait tiquer James Téboul, cf. son commentaire précédemment cité), Xerox, ou encore Sony, soit une entreprise sur deux citées qui va vraiment mal (les autres ayant quelques difficultés ou rien de bien remarquable, y compris chez Motorola, dépositaire de la marque Six Sigma, qui s'est dernièrement scindée en deux avec revente de la mobilité à Google) ; plus amusant encore, pour la France, carton plein avec Air France, Axa, la SG. Bref, pas de miracle, non : le hasard paraît tout aussi efficace.

On a donc fait le tour de la rhétorique et des effets de manche déployés dans la liturgie managériale, celle où l'on décrit un monde où tout un chacun peut être le meilleur, ce qui est pourtant simultanément impossible par définition, dans une guerre économique où les consultants sont les mercenaires du camp qui les paiera (d'où le très grand secret des grands cabinets autour de l'identité de leurs clients ! En effet, on peut les supposer concurrents...). Pourtant, que l'on ne s'y trompe pas : pour ma part, je considère que le management est un art extrêmement subtil (ce qui ne rentre donc pas dans les méthodes pré-cuisinées, du moins pas de manière brute), nécessitant une expérience et une maturité certaine pour être bien mené. J'ai rencontré extrêmement peu de bons managers, beaucoup de mythes (celui du leader, celui qui consiste à mélanger hiérarchie et management, etc.). J'ai surtout pu constater le massacre qui résulte d'un mauvais management, d'un contre-management, du non-management. C'est pourquoi j'ai décidé d'étudier la question ; ça ne veut pas forcément dire accepter le formatage d'esprit, au contraire. Cependant, arrive toujours la question : l'OST, le lean ou tout autre management d'organisation est-il respectueux du travailleur ?

Et pourquoi ne pas assumer, après tout ? Moi-même, je suis fort heureux du confort apporté par les révolutions industrielles, et donc aussi (et principalement) par l'OST. Je ne vais pas cracher dans la soupe par crise de moraline (ou alors, je deviens cynique et vais élever des chèvres dans le Larzac, s'il faut rester cohérent). Si l'on peut faire mieux, que cela profite à tout le monde dans un compromis de production, grand bien en soit-il ; sinon tant pis. Mais en fait cela ne rompt-il pas le charme si l'on explique à l'ouvrier que grâce au lean, dans lequel il est impliqué (notamment par la suggestion d'idées d'amélioration, à cadence industrielle), on va produire plus avec moins, c'est-à-dire supprimer des emplois ? (Et donc se tirer une balle dans le pied si Marx et Keynes ont raison face à Schumpeter/Solow ? — ce qui est plutôt mon avis, d'après la théorie "les arbres ne montent pas jusqu'au ciel" et "l'homme est à dimension finie", tout autant que devant les simplifications affreuses des néoclassiques, les chantres absolus de techno-science couvrant une idéologie pourtant très claire)

Quel abyme ! Et pas même le bon : le sens de la vie ne s'y trouve pas. Les nouveaux dogmes ont ce défaut fondamental, faut-il dire (lisez Legendre !).

Quel est alors mon métier, dans ce fatras de pensée ? Le reportage La mise à mort du travail donne à voir des consultants, dans des séquences absolument extraordinaires. On les voit distiller, par des méthodes passablement grossières pour tout esprit éclairé, leur idéologie dans un aveuglement qui ne connaît pas le questionnement. La théologie du management en est encore à ses balbutiements (elle tourne beaucoup en rond), et dans un très grand paradoxe : nos esprits cartésiens avides de rationalisation (là où il y a l'homme et son mystère !) oublient le fondement (augustinien) du discours de la méthode : le doute. Comme dans toute bonne religion, le doute est banni : croyez, agissez, convertissez. Libérez votre esprit. Quelle promesse séduisante ! Comment lutter ?

Je proposerais donc autre chose. L'auditeur d'une organisation est tel le psychanalyste face à son patient (petite note au passage : on sait par ailleurs tout le débat constant qui règne autour de cette discipline,pourtant indispensable, même pour ceux qui qualifient bon nombre de ses membres de charlatans — à juste titre bien souvent). Le rôle du consultant-auditeur doit être celui du miroir. Ce n'est pas une tâche facile, d'autant qu'un miroir ne peut refléter que ce qu'on lui donne à voir, sans déformer, mais que pour être meilleur encore, il doit au contraire correctement déformer pour compenser la vision de celui qui souhaite se connaître. C'est quelque chose qui m'a interpellé dans une interview d'Alain Minc (que je considère nuisible dès qu'il s'agit d'émettre la moindre idée conduisant à une action, mais dont les diagnostics sociaux sont corrects et dans une franchise déconcertante) : contrairement aux courtisans (ministres et conseillers), il montrait au Président, dans l'ombre, ce que celui-ci ne voyait pas de son action (problème de l'acteur/spectateur), par reflet/réflexion. C'est l'inverse de cabinets qui embauchent de jeunes gens tout juste sortis de l'ENS ou de l'ENA (au mieux de MBA, au pire de grandes écoles d'ingénieur), tel que McKinsey, au sujet duquel j'ai mené mon enquête, tant dans la littérature que parmi mes amis qui y avaient eu recours : leur art est de savoir parler au middle-management (donc de le flatter), par des techniques standardisées, des solutions-miracles qui tiennent au doigt mouillé éclairé, des méthodes pré-mâchées prêtes à appliquer. Leurs 7S sont typiquement de ce cru ; Le prix de l'excellence, écrit par deux de leurs consultants, en est l'émanation même (notons qu'il y a une 2e édition, qui avoue à propos de l'édition de 1982 : "certaines des entreprises présentées en exemples n'ont pas tenu leurs promesses"... Ne nous démontons pas !).

Le vrai métier du consultant, à mon sens, est au contraire de mettre le doigt sur les angoisses et autres refoulements, et d'en faire prendre conscience subtilement, sans brusquer, en respectant ce qu'est le client/patient, sa manière de fonctionner, son identité, en s'inscrivant dans son mouvement pour l'aider à résoudre ses tracas, à lever le malaise qui l'encombre (notons que je parle de fait, a priori, d'organisations qui auraient déjà un problème, et non d'organisations où tout va bien mais où l'on souhaite devenir encore meilleur : avez-vous remarqué qu'en France, on va voir un médecin lorsqu'on est malade, tandis qu'en Chine la consultation est préventive ? Ce n'est pas pour rien que nos méthodes parlent plus de changement — radical chez Six Sigma — que d'optimisation en soi). C'est un exercice d'équilibre qui demande de la patience, de la dextérité, de l'expérience, de l'écoute, une certaine empathie tout en restant objectif (éviter le transfert !), une grande maturité, et beaucoup de réflexion. Ce serait mentir que de claironner y être arrivé : cependant, telle est la voie que j'ai choisie (on aura compris que ce long billet s'inscrit dans ce travail). Dernière (ou presque...) qualité dont il faut faire montre : la capacité de synthèse. C'est quelque chose de particulièrement difficile pour moi (comment ça, ce billet le prouve ?), mais à force d'exercice (écrire un livre aide beaucoup !), ayant pu mener quelques audits ces derniers temps, c'est quelque chose que j'arrive à présent à réaliser ; il s'agit à la fois d'être pertinent, sélectif, efficace et clair. La meilleure méthode, à mon sens, est de faire comprendre avec sensibilité ce qui va et ne va pas : il faut montrer le chemin (et le baliser un minimum, sans pour autant imposer sa vision, ses méthodes, ses fantasmes), mais c'est au client de l'emprunter, car lui seul sait, et lui seul peut agir.

Être un miroir est donc plus complexe qu'offrir une simple réflexion : il faut y mêler toute une analyse pour fouiller discrètement, recouper, et restituer l'image qui convient, celle qui ne s'arrête pas à la surface des choses, celle qui est enfouie. C'est alors que les ouvrages peuvent s'avérer utiles, pour augmenter sa base de données de connaissances, comme un accélérateur d'expérience, comme les épaules d'un géant (parfois de type troll) sur lequel se tenir. Cependant, il faut faire bien attention à la subjectivité et aux idéologies. Ma conclusion est de se fonder prioritairement sur des travaux au cachet scientifique plus éprouvé, ceux de la sociologie (et de l'économie comportementale). Nul besoin de pseudo-théorisation à coup de méthodes pour retrouver le "bon sens" (qui n'en est toujours jamais trop un... Ce serait trop simple !) d'importance du client, de l'horizontalité et du décloisonnement, etc. : tout cela peut, par exemple, se trouver dans le livre de François Dupuy, Lost in management, études sociologiques de cas concrets à l'appui ! On est alors bien loin de la rhétorique habituelle du management (et la franchise est rafraichissante : "on a laissé filer le client", le "sous-travail", etc.). J'irais même jusqu'à dire qu'un très bon livre se reconnaît à ce qu'il pose plus de questions qu'il ne donne de réponses.

La sociologie des organisations est une matière hautement passionnante, dont le travail est toujours en cours. Dans l'excellentissime Les Organisations aux éditions Sciences Humaines (2e édition), qui compile de manière synthétique, sous forme d'articles ou d'interviews, les principales explorations théoriques afférentes aux organisations, on est frappé par le simplisme des approches purement managériales encore enseignées (et appliquées !) dans les écoles de type MBA, dès qu'on arrive à la lecture des théories économiques et sociologiques bien plus poussées — mais le simplisme a pour avantage de pouvoir être packagé et vendu au kilogramme par les cabinets de consultants. Exemple type : la théorie de l'agence. On note là une grande différence, qui fait toute la valeur de cet ouvrage : il s'auto-critique ! (Et la théorie de l'agence, en l'occurrence, s'en prend pour son grade ; il est ensuite amusant d'entendre des consultants diplômés de [E]MBA en parler comme l'alpha et l'oméga de la compréhension des organisations)

C'est aussi le cas de Sociologie des organisations, de Claudette Lafaye (recommandée par un ami sociologue dont c'était la directrice de mémoire, dont il m'a vanté son extraordinaire capacité à tirer du sens de travaux les plus épars), qui fait le point sur la discipline dans la collection 128 d'Armand Colin ("128" comme le nombre de pages, m'a appris ma bienaimée qui en a édité quelques uns). Tandis que le précédent ouvrage a une approche thématique, par fiches pourrait-on dire, celui-ci reprend le fil de l'évolution des théories (uniquement sociales, pas économiques), en pointant leurs filiations historiques, leurs forces, leurs limites, leurs influences, etc. Notons aussi que dans son ouvrage, Claudette Lafaye observe que la discipline managériale louche fortement sur les travaux sociologiques, sans vraiment faire la part des choses, et sans l'approche intellectuelle rigoureuse qui devrait aller de pair. Il faut aussi remarquer que l'on parle toujours là d'organisations, ce qui implique une certaine taille (atteinte par bien peu d'entreprises, si l'on s'aventure sur ce terrain !) ; à ce titre, je ne comprends pas très bien pourquoi on verrait dans le livre d'Eric Ries, à propos des start-ups, quoi que ce soit d'applicable à une bureaucratie hautement peuplée.

Cela étant dit, rien n'interdit, après tout, avec toutes les précautions que l'on aura pu tirer de ces avertissements, d'aller puiser partout de quoi s'inspirer, pour faire germer des idées. Bien au contraire ! Un travail de synthèse permet de se tailler sa propre solution sur-mesure, étoffée, riche. Et c'est ainsi que l'on en revient à notre lean software (rappelez-vous, c'était au début de ce billet...), avec un beau billet chez Yves. Au-delà du vocabulaire (le kaizen, les 5S, j'en passe) et du formatage (quoique j'aime bien les bullet points, c'est lisible :)  ), je suis totalement en accord avec les conclusions, mais en certaine inadéquation avec le cadre retenu. L'important, c'est le fond ; cependant, j'émets une réserve, parce que la forme importe aussi beaucoup : c'est l'emballage, la première approche, celle sur laquelle se fonde le premier jugement. Sur l'esprit, j'ai bien saisi, et je ne suis en désaccord que sur certains points (comme ce terme d'usine, on l'aura compris) ; mais tel quel, je ne pense pas que la perception immédiate soit celle que l'on a voulue, alors que c'est cela qui va faire sens pour le récepteur (il n'est pas non plus à exclure que je me trompe sur ce point). Cependant, je ne pense pas non plus qu'il faille présenter telles quelles les choses : tout le monde (euphémisme) n'a pas l'esprit aussi structuré et boulimique qu'Yves ; on en revient à la capacité de synthèse et de présentation (nos blogs respectifs doivent dont être considérés comme des cuisines, que l'on montre par souci de transparence et de partage, mais les exercices de conceptualisation auxquels nous nous livrons ne sauraient être proposés comme plat final — je tiens à rassurer les lecteurs et éventuels clients qui seraient arrivés à lire jusqu'ici).

En fait, tout comme en politique, on peut choisir de raconter des âneries populistes (café du commerce) ou de faire appel à l'intelligence de ses interlocuteurs-citoyens ; cependant, dans le second cas, il faut garder à l'esprit que la bande-passante, les capacités d'absorption et de compréhension, les intérêts de chacun sont différents. Tout un art, qui va bien plus loin que le simpliste leadership très à la mode de ces derniers temps (surtout pour des gens amenés à être des administrateurs de grosses structures après leur MBA, pas des Napoléon !... Cette rhétorique actuelle des hommes-providentiels/messies est même plutôt néfaste, je trouve). Je me réserve cela, à titre personnel, pour mon propre futur (mon plan de conquête du monde en trois parties et trois sous-parties — je ne me suis toujours pas fait au plan juridique en deux parties). En attendant, je veux bien jouer le rôle modeste d'assistant (mon TJM est raisonnable, engagez-moi !), celui qui dira de faire très attention, et qui, sans tourner au cynisme, en évitant l'immobilisme, en contrebalançant son propre pessimisme naturel (quoique je suis une Cassandre assez efficace), participera à l'action en ayant conscience que les responsabilités entraînent toujours des désagréments qu'il s'agira aussi d'assumer. Être celui qui mettra au service ses talents pour jeter un autre regard.

Un regard franc sur la complexité des choses, pour servir de miroir.



Addendum : Yves écrit à la fin de son billet "Code that grows iteratively needs to be re-factored regularly (iteration yields accumulation); like a garden, it needs constant care and attention." Non seulement je suis entièrement d'accord avec cette brillante formulation, mais j'ajouterai même qu'il en va de même des organisations. Je pense que nous partageons cette vision, en cherchant à "planter des graines" (le "geste fertile" cher à Pierre Legendre, dans un certain sens). Cette métaphore du jardin est même particulièrement riche (la start-up serait un bonzaï ; jardin à la française vs jardin à l'anglaise ; exercice de débroussaillage ; bouture/transplantation de la fusion-acquisition ou du rattachement de service ; j'en passe...). Peut-être vient-on enfin de comprendre le vrai sens de l'expression "culture d'entreprise" !

dimanche, août 31 2008

développement habile (ou l'ôde à la moulinette et à l'enjoyment)

Yannick nous parle beaucoup de développement Agile (souvent très tôt le matin ou très tard le soir, et sans tricher je pense : je me sens donc obligé de répondre un dimanche :)  ). C'est très fashion, à tel point que ça contamine (heu, prophylaxise ?... À voir) même l'embarqué, ce joyeux monde d'électroniciens ratés, mais j'ai un très gros problème avec l'une de ses composantes qui s'applique à moi, ingénieur développeur/intégrateur : l'eXtreme Programming. Par exemple, on se souvient d'un tandem qui a essayé d'introduire la chose chez Thales il y a deux ans et demi, et qui a gagné le trophée de l'innovation pour ça (l'un des deux étant épitéen, et l'autre joueur d'échec, et tous deux bossant juste derrière moi, à Colombes). Mais surtout, j'ai souvenir d'avoir dû y passer moi-même, plus tard : et là, c'est moins drôle.

Mais commençons par un autre bout : oui, il faut des développeurs experts pour pondre les nombreux tests par fonction (heu, procédure : c'est surtout pour les langages pourris type C/Java qu'il est intéressant d'effectuer de tels tests -- mais c'est tellement répandu qu'on en oublie presque que le monde pourrait être parfait et en Caml  :)   ). Et c'est ici que vient s'insérer une anecdote d'un projet réalisé l'année dernière, dans mon ancienne boîte d'électroniciens (80% électronique / 20% informatique -- j'ironise à peine :)  ). Nous prenions pour réaliser les tests des gens en intercontrat, histoire de rentrer dans les coûts, parce que le client veut quelque chose qui marche avec une équipe, pas avec deux. Un jour, nous voyons un des deux développeurs de tests (sur la même machine, XP oblige) commencer à suer gravement : il était depuis deux jours sur un bug, qui arrivait de temps à autre sans prévenir. Et ce n'était pas que le programme à tester était mauvais, enfin, il ne savait pas trop : de temps en temps, segfault sans prévenir. Ciel ! Nous prenons un gdb, et effectivement, quand ça plante, ce n'est pas à moitié : la pile est totalement corrompue. Ça sent le scanf pourri.

Parce que lorsque l'on fait du test de ce genre, on utilise la libc à outrance, et on ne recode pas son parseur ("how many divisions ?"), alors on utilise des choses immondes comme scanf (il faudrait légiférer pour l'interdire définitivement). Bref, nous allons voir le code, et ma foi, il n'y a rien d'extraordinaire. C'est alors que vint l'idée : et si le tableau utilisé n'était pas forcément très ben alloué ? Et la réponse ne se fit pas attendre : "c'est quoi malloc ?". Ne riez pas : lorsque l'on est habitué à faire de l'informatique sur PIC et sans MMU, ça se comprend (enfin, presque, parce qu'un pointeur reste un pointeur, MMU ou pas, il vaut mieux s'assurer que ça ne pointe pas n'importe où). Et ils étaient deux à coder la même horreur côte à côte sur le même PC. Évidemment le bug du test absolument fatal fut rapidement corrigé. On pourra au passage se poser la question d'un bug encore plus mesquin (par exemple tableau alloué à un élément près) qui aurait pu avoir un effet de bord sur les résultats des autres tests (par exemple les déclarer faux alors qu'ils sont exacts, ou pire, les déclarer juste alors qu'ils sont incorrects).

Donc, il nous faut un ingénieur encore plus cher que le développeur, pour faire les tests. Déjà, trouver un développeur à peu près compétent par les temps qui courent, cela relève de l'exploit, et ce n'est pas gratuit ; mais en plus de ça, il faudra plus-que-doubler le coût final pour avoir quelque chose de potable. En ces temps de soldes permanentes que connaît le métier, j'ai comme un doute quant à la pertinence du business model (il va sans dire que le testeur ne doit jamais être la même personne que le développeur, c'est l'évidence même).

Ce que je n'aime pas avec la méthode agile, c'est qu'il s'agit d'une méthode. Ce qui dans le milieu veut dire : un dogme, avec ses gourous. Avant, c'était le cycle en V, que l'on louait beaucoup, malgré les 20% de projets réussis, et 80% de perte en ligne (lors d'une conférence, un commercial vantait son entreprise de génie logiciel qui arrivait au chiffre record de 35% de réussite dans ses projets -- et il était sérieux). Pourtant, le "bon sens" indique que ce système est digne d'un HEC pas bien dégrossi ne connaissant rien à l'informatique, et encore moins à la programmation. Calquer des modèles ne marche pas. Pourquoi ?

Parce que le métier de développeur relève de l'artisanat, et le concepteur d'un programme est un artisan. Il s'agit bien d'un art manuel. C'est pour cela qu'une armée de chinois ne prendra pas notre boulot (et une armée d'indiens non plus), sauf à ce que le travail ne relève plus de l'art, mais du "pissage de code", bête et méchant. De la robotisation, du travail automatique, taylorisé, déshumanisé. Le développement est une discipline artistique (avec des notions de beauté), il ne s'agit pas seulement d'être prompt et aisé dans ses mouvements. J'aime développer pour le vertige du kwrite blanc (contrairement aux chercheurs je ne développe jamais sur feuille : aucun moyen de compiler du papier n'a pour l'instant été trouvé) : il n'y a rien, l'immensité vierge, et il va falloir aller par touches successives mettre en place une cathédrale (à partir d'un bazar, c'est bien connu), échafauder un système complet et suffisant qui pourra effectuer des actions, qui aura des sorties voulues en fonction des ses entrées déterminées.

Tiens, du déterminisme ! Eh oui, à moins de développer le système du Deep Thought (qui est le nom de mon PC portable sur lequel j'écris, d'ailleurs), auquel cas un "return 42;" sera plus rapide, un programme informatique a des entrées attendues, et des sorties associées (en ce sens, on peut faire l'analogie avec une application mathématique : ne jamais oublier aussi que l'informatique est une branche les plus complexes des mathématiques, et dès lors que l'on sort de ce cadre, on fait de la peinture rupestre si l'on veut -- désolé pour les "développeurs" html --, mais certainement pas de la programmation !). Et nous pouvons donc tester directement en fonction de ces entrées et sorties depuis l'extérieur en mode "boîte noire" : c'est ce que l'on appelle une "moulinette de test", par exemple un script shell géant gérant toutes sortes d'appels (y compris devant générer des erreurs), et scannant la sortie pour nous répondre des OK ou des KO.

Il y a deux restrictions à cela : tout d'abord, le procédé peut paraître "grossier", en ce sens qu'il n'a pas la même profondeur de détail que le "test unitaire" (dont le nom est ambigu, d'ailleurs). On pourra répondre par la modularité nécessaire des grosses applications, par la nécessité de toujours mettre des hooks de debug sous macro (un "#if TEST", tout simplement), faisant des printf ou autres joyeusetés qui vont bien (attention cependant aux applications temps réel), et par le fait qu'empiler des briques préjugées correctes ne garantit pas non plus que le résultat final sera bon (pour répondre au présupposé agile). Ensuite, la limite de la moulinette se situe dans la programmation graphique.

Que l'on ne s'y trompe pas : l'XP a été créé pour et par des "génie logiciel" (attention aux acceptions de "génie" :)   ). Et l'on connaît les classeurs de centaines de page de test du style "cliquer ici, là, re-ici, etc, vous devez alors trouver blabla dans la zone de texte à droite". Sauf que c'est ici un faux problème : tout bon développement se fait en ligne de commande, et la partie graphique ne doit être qu'une interface qui... s'interface (c'est donc pour ça le nom ? :)   ). C'est exactement de cette manière que sont codés la plupart des applications sous KDE, ne serait-ce que parce que Qt est conçu dans cette optique précise.

L'habileté d'un programmeur ne se situe donc pas dans sa capacité à répondre à un schéma préétabli, dans lequel on le forcer d'entrer. Il est très politiquement incorrect en ces temps gouvernés par le seul aspect commercial ("combien de temps pour faire ceci ou cela", avec comme prérequis "le temps, c'est de l'argent") de déclarer cela, mais il ne faut pas oublier que le métier de développeur est celui de l'artisan. On peut tout à fait faire des choses et des bidules correspondant à des exigences précises mais que l'on qualifiera aisément d'usine à gaz tout de même (on en a quelques exemples dans le logiciel libre, et pour ne pas froisser Sophie on se contentera de citer Firefox). Un programme n'est pas une somme de fonctionnalités, c'est un tout, c'est une oeuvre (au sens juridique aussi, un bon indice !), une sculpture numérique, une composition (la musique, cette autre branche artisitque des mathématiques), ou une toile du XIXème (qui se fait par ajout successifs de couleur, par dégrossissement : il n'y a rien de mal à ne pas terminer immdiatement le codage d'une fonction quand cela s'avère nécessaire !) (je précise "XIXème" car je ne voudrais pas que l'on compare mon travail à du Picaso, Miro, ou autre horreur du genre commis le siècle suivant -- et qui se vendent aussi cher que cela aura pris peu de temps à faire, mais n'a pas son siège social à Redmond qui veut !).

Il fut un temps où la mode passa au tout-objet (en tant que méthode technique de développement, cette fois). Dijkstra avait alors déclaré : "Object-oriented programming is an exceptionally bad idea which could only have originated in California." Et pour nous convaincre qu'il n'aurait certainement pas trop aimé la tournure des choses actuelles : "Program testing can be used to show the presence of bugs, but never to show their absence!" Nous sommes toujours orientés dans cette optique, malheureusement.

Que l'on ne s'y trompe pas : le bon sens de la méthode Agile est à suivre (comme tout véritable bon sens), et l'on peut très bien arriver à des conclusions justes (du genre "on livre un programme qui marche, et dans les temps" -- qui est d'ailleurs aussi pris en hypothèse, méthode de raisonnement habituellement chère à la chimie, cette branche obscure de la cuisine) à partir d'hypothèses fausses ("la programmation n'est pas de l'artisanat et soumise à des méthodes fixes", ou autre), avec un raisonnement juste (table de vérité par ici). C'est incroyable, mais le "Release early, release often. And listen to your customers." ressemble très fortement à "Customer satisfaction by rapid, continuous delivery of useful software". Eh oui, le modèle du logiciel libre se fait pomper ! C'est peut-être parce que le logiciel libre marche extrêmement bien, non ? (dans une SSLL, ce serait un comble que de devoir convaincre son lectorat :)  ) Et que donc la méthode appliquée est certainement la meilleure qui soit ! C'est moins vendeur, c'est certain : du bazar  :). On pourrait peut-être renommer ça en "recuit simulé" ? (ah non, c'est déjà pris)

Allez, gardons le dernier mot pour feu notre Grand Gourou Dijkstra (dont il faudrait presque citer l'intégralité) :

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.


update (30/10): après discussion avec Yannick, je suis totalement convaincu du bien fondé de la méthode (surtout qu'il existe à présent de vrais outils pour la mettre en place et coordonner, contrairement à ce que j'avais vécu il y a plusieurs années), même si je reste toujours sceptique vis-à-vis d'un gros développement en C, surtout embarqué/système. Mais je suis totalement ouvert à la méthode Agile en tant que gestion de projet, hors eXtreme Programming on l'aura compris  :). Ayant pu depuis tester le talent de son plus ardant défenseur à Linagora, je m'avouerais même fort intéressé : c'est bien connu, il n'y a que les imbéciles qui ne changent pas d'avis ! :)  ("cette pirouette rhétorique vous a été offerte par...")