Interview Pierre Pezziardi

Le 1er European Lean IT summit aura lieu les 13 et 14 Octobre à Paris au Cercle National des Armées. Une excellente opportunité pour faire le point sur l’adoption de cette approche industrielle dans le monde du développement logiciel, le Lean Software Development.

Une distribution prestigieuse avec, entre autres, la spécialiste du sujet (l’épatante Mary Poppendieck co-auteur du tryptique fondateur sur le sujet) et notre champion national, Pierre Pezziardi, auteur l’an dernier chez Eyrolles de Lean Management et Informatique conviviale.

Un ouvrage remarquable qui traite des mésaventures d’un DSI au sein d’un grand groupe bancaire. Sous forme de fiction (l’ombre du regretté Eliyahu Godratt) ce livre permet à l’auteur de mettre en scène les principes forts qu’il défend et les confronter à des personas de l’organisation.fr croqués avec justesse et vérité, dans leur cynisme, leur vulnérabilité et leurs doutes.

Ces principes sont ceux du manifeste de l’informatique conviviale :

• Des systèmes en amélioration continue
• Aussi simple de s’en servir que d’y contribuer
• Où tout ce qui n’est pas explicitement interdit est autorisé mais tracé et réversible
• Et où ceux qui rendent leur poste obsolète sont promus

Pierre nous a fait l’honneur de répondre sans se défiler aux questions de #hypertextual pour creuser ce manifeste et discuter de cet ouvrage à mettre entre les mains de tous les DSIs.

1) Une des premières missions de votre héros, Paul, est d’identifier le but de son organisation en une phrase simple et claire. Cela semble tellement évident et pourtant peu d’organisations s’attellent à cette tâche fondatrice. Commet l’expliquez vous ?

Parce que nous avons essentiellement un regard analytique sur les systèmes complexes, un héritage cartésien probablement. La lettre de mission d’un DSI contient 48 objectifs et sous-objectifs, le problème est ainsi posé : il faut respecter le budget ET  normaliser les processus ET assurer la disponibilité ET aligner le système sur la stratégie ET … C’est le point de vue dominant de frameworks comme ITIL ou Cobit.

Mais cette vision analytique peine à rendre compte de la réalité d’un système complexe, où de petites causes peuvent produire de grands effets (papillon) : ajouter une étape de “conformité de l’architecture au schéma directeur” peut doubler les délais de livraison des projets par exemple. L’exercice de maïeutique avec Paul lui fait reconnaître cette impossibilité de poursuivre plusieurs buts à la fois, puisque dans les nano-actions du quotidien, les individus seront immanquablement tiraillés entre objectifs contradictoires (plus vite ou plus sécurisé ? moins cher ou plus vite ? ..).

En substituant cette vision analytique au profit d’une vision systémique, votre perception du problème va changer radicalement : en réalité, le système est un organisme complexe difficilement modélisable comme la somme de ses parties indépendantes (Edward Deming : “tous les modèles sont faux, certains sont utiles”) : elles sont au contraire étroitement imbriquées. Plutôt que le découper vainement, reconnaissons la nécessité d’extraire une mission principale (celle qui nous vaudra le salut des utilisateurs), sous contrainte de quelques autres objectifs. Ainsi “maximiser le débit de demandes utilisateurs sous contraintes de coûts et de risque (panne, bug, faille)” est un puissant schéma directeur en ce qu’il peut diffuser clairement du management aux opérationnels.

Voilà, c’est donc la faute à René (Descartes).

2) Votre cartographie du SI axée sur 3 paramètres (valeur vue des utilisateurs, coût total de l’application, passif du système) est particulièrement audacieuse et révolutionnaire. Comment parvenir à vendre cette représentation aux directions ?

La cartographie n’est pas si difficile à vendre aux directions, c’est beau, simple et compréhensible (je me souviens d’un séminaire chez Bouygues Telecom où le terme “croute” avait été adopté par une assemblée de dirigeants ayant tout de suite compris le concept de dette technique). Cet outil a été adopté par la Direction Générale de la Bred en moins d’un an. La réelle difficulté réside dans l’impact réel de cette cartographie “en responsabilité” (les coûts s’entendent Développement et Production), si elle n’est pas alignée sur une organisation en responsabilité.

Je m’explique. Si vous utilisez cet outil, mais que Etudes et Production sont deux directions distinctes, vous ne ferez qu’augmenter le nombre de conflits (ce sont /tes/coûts, /ton/ problème ..) ! Dans une organisation en responsabilité Produit (you build it, you run it, ou devOps comme on dit), elle permet au contraire aux responsables de maîtriser l’impact de leurs actes, par exemple investir 100 j.h de développement pour simplifier cette chaîne batch et gagner de la puissance machine instantanément visible dans le coût global du produit ou sa dette …

3) Dans votre livre, vous mentionnez indirectement de nombreuses méthodes et pratiques Agiles (TDD, User Stories, Scrum Boards, équipes pluridisciplinaires etc …) sans pour autant vous y attarder. On sent cette volonté de défendre une démarche globale (Lean) plutôt que des méthodes. Est-ce à dire que ces pratiques ne sont pas importantes dans la mise en oeuvre d’une démarche Lean ? Quels conseils donneriez-vous pour articuler ces méthodes Agiles avec cette démarche Lean ?

Au-delà du fait qu’il existe du contenu de très grande qualité sur ces techniques, il m’a semblé important de rester au niveau de la démarche globale, pour exhiber le problème de fond, et ne pas s’en détourner. Aujourd’hui il existe de plus en plus d’équipes agiles, mais toujours aussi peu d’utilisateurs satisfaits. Étonnant non ? Nous voyons d’ailleurs fleurir tout un tas d’orthodoxes prêchant le “plus de tests automatisés”, “plus de mixité des disciplines”, “plus de planning game”, et ce faisant, polarisant notre attention sur des problèmes d’ordre 2, là où notre problème d’ordre 1, c’est maximiser le débit de demandes qui satisfont les utilisateurs. Ne vous laissez pas divertir par l’arbre qui cache la forêt… Mon conseil aux agilistes : ne vous croyez pas dépositaire d’une méthode magique (si si), mais plutôt d’une boîte à outil, dont on pourra se servir progressivement, au fil des améliorations qu’impose le BUT à l’ordre 1.

4) Vous avez une approche assez radicale, inspirée de Eliyahu Godratt de l’accompagnement du changement : si on propose des solutions que les gens veulent et qui résolvent un de leur problème il n’y a pas besoin d’accompagnement du changement. Est-ce vraiment aussi simple dans nos organisations ultra-complexes ?

En fait oui, mais je précise. Lorsque vous pénétrez un système, il a trouvé un certain équilibre, même si vous pouvez le juger médiocre. Vous ne pouvez donc pas le changer à moins d’avoir la pleine adhésion des gens qui y vivent. Je ne soutiens un changement qu’à deux conditions :

• il existe un écart fort entre la devise (le BUT) et les résultats de cette équipe (par exemple un centre de support qui ne résout pas bien les demandes utilisateurs)
• il existe une personne décidée à ne plus tolérer cet état de fait.

6) Vous faites référence en permanence à la confiance que vous citez par ailleurs comme élément central du manifeste de l’informatique conviviale. Pourquoi selon vous avons nous tant de mal à se faire confiance dans nos entreprises ?

Je suis convaincu que plusieurs facteurs conduisent à privilégier la méfiance sur la confiance en entreprise, dès qu’elle atteint une certaine taille. Le premier est cité dans le point précédent, il est difficile pour un employeur de garantir l’emploi, et donc tout le monde cherche à se rendre indispensable, créant ainsi tout un tas d’activités centrés sur le contrôle plus que sur la coopération opérationnelle (marque de confiance). Lénine disait avec justesse “La confiance n’exclut pas le contrôle”, mais quand plus de 50% de la valeur ajoutée des pays occidentaux est consacrée non pas à faire les choses, mais à les compter, les contrôler ou les planifier (source BCG), le système s’est clairement emballé…

Albert Jacquard ou plus récemment l’économiste Yann Algan suggèrent quant à eux une racine plus profonde, issue de notre éducation, où les bénéfices d’une saine émulation se sont effacés derrière les dommages créés par une féroce compétition. Au fond ils ont raison, nous faisons de brillantes études, mais combien de diplômés de grandes écoles savent accepter une critique ou résoudre un conflit ? Coopérer, c’est accepter l’autre, et c’est bien connu, l’enfer c’est les autres (non chérie, je préfère que tu prennes ta voiture, pas la mienne .. ;-).

7) Vous identifiez avec justesse de nombreuses tensions entre des valeurs opposées dans votre ouvrage : spécialisation et autonomisation, sédentarité et nomadisme, innovation et opération. Quel est votre conseil pour gérer ces tensions et déterminer si l’on positionne le curseur au bon niveau ?

J’ai une technique simple, un mot : ET. Nous vivons dans un monde qui aime les oppositions. On est de droite OU de gauche, écologiste OU pro-nucléaire, Lacanien OU Freudien .. Toutes nos élites nous présentent un monde clivé, où chacun défend LA solution. Je vous propose un autre monde : en fait les pro et les anti-nucléaires ont raison, il faut juste admettre que l’on va garder des centrales (conservateur) ET en éteindre au profit de nouvelles sources (innovateur) ET améliorer la filière de recyclage (innovateur). Chez nous, nous avons par exemple convenu que le plan annuel contiendrait aussi des enveloppes “innovation”. Le top/down, le planifié, ne s’opposant ainsi plus au bottom-up, la meilleure idée du terrain, inconnue il y a à peine quelques jours… Quant au curseur, je n’ai pas de recette, quand on est à 0-100, passez à 10-90 et observez, puis réajustez.

8. A de nombreuses reprises, vous faites référence  aux réseaux sociaux d’entreprise (Wikis, Microblogging etc …). Quel rôle pensez vous que ces outils seront amenés à jouer dans les organisations de demain ?

Ils le jouent déjà, mais à l’extérieur de l’entreprise, regardez Wikipedia ! Mais ils ont misé sur la confiance : vous pouvez aller, là, maintenant, éditer la page sur l’existentialisme. A l’intérieur de l’entreprise, règne au contraire les règles de la méfiance, qui vous empêcheront de corriger un chiffre ou une faute d’orthographe de votre collègue de la comptabilité. Ces outils vont donc fleurir, mais sans que l’on modifie les règles profondes de l’entreprise, ils ne serviront à rien. J’avais répondu à Thierry Breton à ce sujet.

9) Au final, votre fiction est plutôt pessimiste. Pour quelle raison pensez vous que malgré une valeur indiscutable, cette démarche Lean, ces pratiques agiles et ces outils collaboratifs (Wikis, microblogging etc …) adoptés sans réserve dans le monde du logiciel libre ont-ils autant de mal à s’imposer dans nos organisations ?

Je ne suis pas pessimiste, mais réaliste. Les organisations open source se sont développées sur un “ADN” différent, la confiance et la coopération, précisément parce qu’elles y étaient forcées ! La pénurie de ressources les a contraintes à innover du point de vue des pratiques industrielles classiques. En entreprise, sans urgence de cette contrainte, l’équilibre ancien persistera. On le voit bien dans le faible nombre d’entreprises ayant opéré un changement drastique de mode de gestion vers le participatif (et pas les milliers d’ersatz de “lean management“, avec leur département Méthodes, leur schéma directeur d’amélioration continue ou leur simulacre de démocratie ouvrière masquant l’absence d’autonomie dans l’amélioration de leurs process). Seules celles confrontées à des crises ont risqué le changement. La crise majeure de productivité que traverse l’Europe pourrait constituer un tel levier de remise en question …

10) Le dernier point de votre manifeste est l’exhortation à promouvoir les personnes qui diluent leur tâches dans les communautés ouvertes créées. Comment vendre cela à des DRH ?

Les DRH ne sont pas les décideuses, elles appliquent la politique de la Direction Générale. C’est au niveau de ces Directions Générales que peut se faire le choix, risqué convenons-en, d’un changement profond vers plus d’autonomie des unités de production, qu’il s’agisse d’écoles, d’usines ou de directions informatiques…

Merci beaucoup d’avoir pris le temps de répondre à nos questions. On vous retrouve le 13 Octobre au Lean IT Summit.