Archives de la catégorie ‘Mieux, plus vite, avec les mêmes personnes’

Whatever the bottleneck produces in an hour is equivalent to what the plant produces.
Every hour lost at a bottleneck is an hour lost in the entire system.

Eliyahu Goldratt

Le pilote Global Search est un immense succès. Les techniques de développement à cycles courts par des équipes intégrées en recherche d’amélioration continue ont montré leur viabilité à petite échelle. Si je veux exhiber des résultats à Montleau, il va me falloir reproduire l’initiative en la multipliant à d’autres endroits. Mais partout le code génétique est inversé : cycles longs, équipes spécialisées, relations contractuelles, standards figés. Qui donc choisir comme prochain candidat au changement ?

Puisque je tiens désormais une première équipe formée aux nouvelles méthodes, je peux tenter une diffusion par division cellulaire : prendre une moitié du groupe et l’injecter dans une partie du SI où elle pourrait obtenir des résultats …

Je contemple notre nouvelle carte d’état major.

Sur de nombreuses applications, en complément de l’actif, du passif et du coût total, Kasperski y a ajouté un quatrième indicateur intéressant : le nombre de demandes non-traitées. Ce volume représente le stock en attente par les utilisateurs. Plus il est important, plus les gens sont mécontents, et souvent à titre légitime. Tiens, à la comptabilité, il y a un système de « Rapprochement Risques » qui possède tous les attributs du « gagneur » : rapport valeur/prix prohibitif, dette technique abyssale et stock de demandes monstrueux. L’ambiance doit être détendue, ironisé-je intérieurement. J’imagine de pauvres utilisateurs pressés par le régulateur de justifier les milliers d’écarts entre les calculs réalisés par la Direction des Risques et ceux réalisés par la Direction Financière – chaque contrat de la banque étant évalué avec des méthodes et des systèmes différents – et les informaticiens incapables de leur livrer les outils dont ils ont besoin pour réaliser cette mission … Au point où ils en sont, introduire de nouvelles pratiques ne peut qu’améliorer les choses, ils devraient donc nous réserver bon accueil.

*

Quatre mois se sont écoulés depuis ma décision d’étendre les nouvelles méthodes. Kasperski a rayonné sur les deux équipes, Jean-Pierre a pris la tête de l’initiative CRM – glorieux retour dans sa saison 2 ! – et Jérôme, mon ancien pompier du dimanche, celle du Rapprochement Risques.
L’ancien Directeur du programme Global CRM a hurlé à l’imposture en invoquant « la simplicité du petit projet Global Search, qualifiée bien hâtivement de modèle pour la généralisation d’une méthode artisanale n’ayant pas fait ses preuves ». Il a démissionné de son poste de manière aussi tonitruante que Jean-Pierre à l’époque. Leurs approches du projet n’étaient définitivement pas conciliables.

Côté Direction Financière, le plus ardu pour Jérôme a été de convaincre les différentes parties prenantes de se réunir sous une direction unique et dans un lieu unique. Bien que tout le monde s’accordât sur l’inefficacité d’une organisation spécialisée par profils – utilisateurs, représentants utilisateurs, développeurs, architectes, intégrateurs, testeurs et j’en passe -, aucun ne souhaitait abandonner son territoire. Le tropisme bureaucratique demeure puissant et fait obstacle aux solutions de bon sens. J’ai dû sortir le chéquier en promettant un variable sur les résultats finaux et m’affranchir du dernier récalcitrant, l’irréductible du cahier des charges et du contrat formel entre équipes. Parfois notre éthique se rapproche plus de la morale des Princes prônée par Machiavel – la fin justifie les moyens – que de celle du Gentilhomme avancée par Kant – agis de telle sorte que tu traites l’humanité aussi bien dans ta personne que dans la personne de tout autre toujours en même temps comme une fin, et jamais simplement comme un moyen. A moins que ce ne soit faire preuve de respect que de l’écarter avant qu’il ne provoque autant de dégâts sur l’équipe que sur lui-même. Comme quoi « tous les modèles sont faux, certains sont utiles ».

Je retrouve Jérôme à son bureau pour un point informel. L’open space est organisé en ilots où siègent quatre à cinq personnes, souvent en discussion, parfois au travail par paire sur un même ordinateur. Plus open et moins space qu’avant, quoi que.
Des indicateurs visuels sont présents sur les murs, je reconnais instantanément le graphe de débit de demandes, qu’on appelle ici vélocité. La courbe est chaotique, mais suit une pente ascendante. Enfin Jérôme vient à ma rencontre :

– Comment allez-vous Paul ?

– Très bien, je vois que le débit est bon, les utilisateurs sont-ils satisfaits ?

– Ils peuvent ! En trois mois nous avons livré la totalité des demandes en stock, ils n’en revenaient pas !

– Du coup vous faites quoi maintenant ?

– Justement je voulais vous en parler, pouvez-vous m’accorder un instant s’il vous plaît ?

Il m’entraîne au calme dans son bureau et ferme la porte.

– Vous voyez Paul, les utilisateurs sont contents, mais j’ai l’impression que la direction n’est pas tant que çà en phase avec ses troupes …

– Comment ça ?

– La semaine dernière, Sibylle Barrière-Johannel, la directrice financière, s’est invitée au comité de pilotage et a examiné nos chiffres, notamment les dépenses. Elle a reconstitué nos coûts unitaires, et s’est exclamé « qu’à 1 500€ le jour homme, on était environ trois fois plus élevés qu’ailleurs ! »

– Pourquoi ne pas m’avoir prévenu plus tôt ? Vous ne savez pas ce qu’une telle sortie signifie ?

– Je n’ai pas compris tout de suite, mais ce n’est pas tout. Elle a ajouté que puisque le stock de demandes était traité, la nouvelle équipe informatique était en surcapacité. Il fallait donc supprimer des postes.

– En somme on va sanctionner les personnes qui ont réussi à obtenir les plus gros gains de productivité ! Cette équipe était autrefois le goulet d’étranglement de tout le système, et maintenant qu’elle ne l’est plus, grâce à votre action, la Direction Financière ne veut pas accepter que ce goulet se déplace dans d’autres services.

– Tout à fait, maintenant, ce sont des audits de filiales, des demandes d’engagement budgétaire qui s’accumulent dans les services.

– Plutôt que de réfléchir à de nouvelles demandes d’amélioration qui permettraient d’augmenter la performance globale de sa Direction, elle exige de diminuer vos coûts ! Ce n’est pas comme ça que nous ferons progresser l’entreprise. Je vais de ce pas la rencontrer. Je vous tiens au courant Jérôme.

*

Sibylle est une femme d’environ 35 ans, c’est la benjamine du Comité de Direction. De ce que je sais, elle a commencé sa carrière fulgurante dans l’audit puis dans la banque d’affaire.

Sa secrétaire m’obtient une entrevue pour ce soir, ce qui me laisse le temps de contacter Secrotas pour la préparer. Mes connaissances actuelles en Théorie des Contraintes m’ont permis d’opérer un diagnostic de bon sens, mais je ne suis pas confiant dans ma capacité à le défendre face à la Directrice Financière de la Générale.

– Vous voyez, Jean-Louis, il va me falloir expliquer que l’organisation doit s’envisager comme un tout et non pas comme la somme de ses parties. Pourquoi si peu de variables – voire une seule – limitent la performance d’une organisation à un moment donné. Argumenter sur ce concept de goulet, de pilotage de la chaîne critique par le débit plus que par les prix de revient…

– Je vois, mais vous me semblez très à l’aise, vous avez pris le temps d’éplucher quelques ouvrages de maître Goldratt on dirait ?

– Cela ne fait malheureusement pas de moi un expert tout terrain ! J’appréhende la dialectique comptable. Comment contrer l’argument de la surcapacité ? En quoi préserver notre capacité garantit-il qu’on l’utilisera pour des améliorations avec un impact sur la performance globale de l’entreprise, telle que mesurée par la Direction Financière ?

– Question judicieuse. C’est vrai, peut-être faut-il diminuer la capacité, non ?

– Trouvons plutôt des demandes qui, si elles étaient intégrées au SI, rendraient plus efficace la Direction Financière !

– Vous avez une idée pour cela ?

– Eh bien, oui. Celle que nous avons appliquée lors du projet Global Search : imaginer une innovation qui semble créer de la valeur pour les utilisateurs et lui appliquer le test infaillible de Goldratt : « Quelle est sa force, qu’apporte-t-elle de nouveau ? Pour une entreprise qui souhaite la mettre en place, quelle limitation de ses performances permet-elle de diminuer ? Et enfin : quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation ? »

– Qu’est-ce qui vous fait penser qu’un flux d’innovation n’est pas concevable durablement ?

– Je ne sais pas. Les personnes responsables d’exprimer les demandes utilisateurs n’en fournissent plus.

– Ce « poste de travail » est donc probablement la nouvelle contrainte du système, à laquelle est subordonnée toute la production de valeur informatique. Comment pourrions-nous travailler sur cette contrainte comme nous le suggère la TOC ?

– Il faudrait augmenter le débit d’idées à la source pour obtenir après filtrage plus de demandes ayant une valeur réelle.

– Hum …

– Nous pourrions obtenir davantage de l’équipe spécialisée dans l’élaboration des demandes en l’ouvrant sur l’extérieur par des ateliers pluridisciplinaires où l’on jouerait à faire émerger des idées, qui seraient ensuite perfectionnées en appliquant la dialectique « innovation » : quelle nouveauté ? quel impact sur quelle limite ? quelles règles du système changer ?

– Parfait. C’est à tenter en tout cas. Je dois vous laisser Paul, vous êtes sur la bonne voie, ne vous en faites pas pour votre entretien tout à l’heure !

– Facile à dire à l’autre bout du téléphone ! Merci quand même Jean-Louis.

*

Sibylle m’accueille tout sourire dans son immense bureau, lumineux et ordonné. C’est incroyable d’ailleurs, elle doit bien avoir un espace double du mien, sans compter la vue imprenable, et pourtant nous occupons le même rang hiérarchique dans l’organisation. Quelle injustice !

– Alors Paul, la forme ?

– Oui merci, et vous ?

– Excellente. Grâce à nos efforts, le rapprochement comptable occupe désormais trois fois moins de monde et se dénoue en deux fois moins de temps ! Votre unité de combat en mode commando était finalement une idée intéressante, un peu chère, mais la marche forcée a permis de rattraper notre retard. Maintenant il est peut-être temps de rentrer à la caserne ?

– Hmm. Que vous voulez dire par là ?

– Eh bien, le travail est terminé, il est temps de retrouver un rythme normal, de réintégrer les troupes dans leur département d’origine, diminuer les coûts, revenir aux normes de qualité que nous connaissons …

– Mais on n’a jamais produit autant de qualité qu’avec ce mode d’intervention !

– C’est ce que vous dites ! Pour ma part j’attends toujours la note d’investissement, le cahier des charges validé, les spécifications détaillées. Vous pensez que l’absence de traçabilité est une marque de qualité Paul ? Et l’inflation des coûts ? 1 500€ la journée dans vos équipes, on nage en plein délire, même les traders ne gagnent pas autant !

– Permettez-moi de reprendre vos points un par un. La traçabilité n’a jamais été aussi bonne, puisque, même sans cahier des charges ou spécifications détaillées, chaque fonctionnalité est tracée dans notre base de demandes, de laquelle sont issus les tests concrets à passer ; lors de la dernière démonstration, nous avons eu par exemple « un contrat de crédit litigieux d’un million d’euros, ayant 44 jours de retard, passe 3400€ de provisions dans le compte provisions sur créances douteuses de la comptabilité générale ». Et je ne parle pas d’un document de test forcément en décalage avec la réalité, je parle de tests exécutables qui permettent de valider vous-même n’importe quel aspect du système, tel qu’il est réellement en production.

– Et vous voulez aussi que je me mette à programmer, tant que vous y êtes !

– Ce n’était pas mon propos, Sibylle. Sachez simplement que ce patrimoine de tests automatisés nous permet de garantir un logiciel adaptable en permanence, prêt à accueillir vos prochaines innovations.

– Avec des ressources à 1 500€ la journée, je pourrai même rendre adaptable un bloc de béton armé !

– Quant aux coûts unitaires, ils sont effectivement élevés. Mais quand nous avons fixé les bonus de l’équipe si elle délivrait la valeur attendue, le coût total représentait une fraction dérisoire de la valeur totale créée pour la Générale. Aujourd’hui, l’équipe a délivré bien au-delà de cette valeur – que vous observez dans l’augmentation spectaculaire de la productivité du département Rapprochement – il était normal que la Générale tienne ses engagements, car au final elle est gagnante : les fonctionnalités ont été délivrées pour un coût global dérisoire en proportion des gains.

– Oui mais quand même, le triple des prix de revient moyens constatés dans le reste de la DSI !

– Ecoutez Sibylle, je suis venu vous proposer d’étendre ce mode d’organisation à toute la Direction Financière. J’aimerais d’ailleurs discuter avec vous des limites de la comptabilité analytique par les prix de revient. Vous savez, piloter ces grandeurs intermédiaires virtuelles peut nous conduire à préférer les optima locaux à l’optimum global pour l’entreprise, comme par exemple remplacer du personnel à 1 500€ par du personnel à 500€, sans en mesurer l’impact sur le débit …

Un homme nous rejoint discrètement dans le bureau. Tiens, Gérard, l’ancien directeur du programme GlobalCRM, que peut-il bien faire ici ?

– Et maintenant vous voulez m’apprendre mon métier ! reprend Sibylle. C’est le pompon ! Ecoutez Paul, Gérard qui a rejoint mes équipes récemment est également de mon avis : hausse des coûts, absence de contrôle, désorganisation, cela fait trop. Nous en avons parlé à Henri de Montleau, qui partage ce constat. Nous en reparlerons donc avec lui si vous voulez bien.

– Très bien. Très bien. A bientôt donc.

Je sors abattu du bureau en me remémorant cette maxime de Tocqueville : « En politique, la communauté des haines fait presque toujours le fond des amitiés. ».

*

Une colère indescriptible m’envahit tandis que je retourne dans mon bureau dont l’aspect minable me saute soudain aux yeux. L’absence de vue, de bois précieux, et le désordre achèvent de m’accabler. J’appelle Secrotas dans un réflexe de rage :

– Secrotas, je me suis fais exploser, vos théories ne sont pas entendues !

– Ce n’est peut-être qu’une bataille de perdue, essayons de …

– J’en ai assez de vos conseils parcimonieux, c’est trop facile de se cacher derrière un téléphone et de ne jamais assumer !

– Bip bip bip.

Il a raccroché le fumier ! Il m’a raccroché au nez ! Je tape du poing sur mon bureau, j’envoie valser la pile de dossiers déjà largement épanchée sur la table, et je hurle. J’enrage vraiment. J’observe hagard le désordre aggravé. Je suis vidé.

On frappe à ma porte.

– Je veux la paix, fichez-moi donc la paix Hélène !

– C’est un certain Monsieur Secrotas, il dit que vous avez été coupés …
Je me lève d’un bond pour ouvrir, redynamisé par la curiosité. Je commence à réaliser à quel point il m’a aidé sans que jamais nous ne nous rencontrions. A quoi peut-il bien ressembler ? Comment peut-il être ici quelques secondes après avoir raccroché, alors que je l’imaginais dans quelque bureau ou pays lointain ?

Un homme discret, de taille moyenne, tenue décontractée, arrive dans mon bureau en me tendant la main, un sourire délicat au coin des lèvres. Je ne peux m’empêcher de le lui retourner :

– Veuillez excuser le désordre, il y a eu de l’action récemment …

– C’est ce que je constate !

Je réfléchis quelques secondes tout en le dévisageant et poursuis :

– Nous nous sommes déjà croisés non ?

– Autrement qu’au téléphone ?

– Oui. Cela me revient. Il y a un an environ, lors d’une réception au Ministère des Finances. Vous présidiez le jury du prix Entrepreneuriat & Croissance. J’avais accompagné Henri de Montleau qui recevait son trophée en récompense de sa politique de financement volontariste en faveur des jeunes entreprises. Je me souviens de votre commentaire sur le partenariat gagnant-gagnant qu’Henri avait su tisser avec l’ANPE…

– Effectivement, c’est là que j’ai connu Henri.

– Alors vous allez peut-être pouvoir m’aider. Sibylle Barrière-Johannel est en train de monter un front contre nous et nos nouvelles méthodes, elle prétend avoir le soutien de Montleau.

– Vous savez Paul, ce que je vais vous dire risque de ne pas vous plaire, mais comme vous devez l’imaginer, ce n’est pas la première fois que j’aide une entreprise à se transformer. J’ai débuté ma carrière en rendant plus efficaces les usines contre lesquelles toutes les organisations industrielles pestaient, un peu comme l’usine à logiciel qu’est la DSI. Nous y avons appliqué les techniques de la TOC, et elles ont souvent conduit à des résultats extraordinaires. Mais voyez-vous, dans très peu de cas ce changement s’est avéré durable. Pire, beaucoup d’usines ont reçu en pleine figure le boomerang de leurs améliorations, dans des conditions très exactement identiques à ce qui se produit ici : prix de revient en hausse, excédents de capacité, donc nécessité de réduire les « coûts ». Qui plus est, l’usine est historiquement le centre d’exécution, et il est difficile pour des directions « amont » de valoriser une innovation provenant de la « soute ». Aucun bureau d’étude, aucune force commerciale n’était prêt à accepter d’être le nouveau goulet, et d’entamer une introspection et un changement à son tour.

– Vous saviez donc que j’allais au casse-pipe depuis le début ?

– En quelque sorte oui. « Chaque fois que l’on produit un effet, on se donne un ennemi. Pour être populaire, il faut rester médiocre » disait Oscar Wilde ! Mais la bonne nouvelle, c’est qu’Henri le sait aussi ! Il ne vous laissera pas tomber. Il est conscient de tous ces effets, et je peux vous assurer qu’il a en tête une approche holistique de la question, partant de la DSI, mais s’étendant à toute l’entreprise.

– Mais alors Sibylle bluffait ?

– Probablement, mais vous ne devez pas vous en soucier.

Je digère ces révélations avec délectation. Quand je lève les yeux, Jean-Louis a toujours son sourire délicat, et mon bureau me semble tout à coup immense, agréable, confortable…

Tiens, je vais prendre quelques jours de vacances, moi.

-> Chapitre 6

« Les règlements sont faits pour les soldats et non pour les guerriers ; la bataille se rit du code, elle en exige un nouveau, innové par elle et pour elle et qui disparaît dès qu’elle est terminée. »
Napoléon Bonaparte

Le Guinness des records devrait enregistrer ce week-end comme le plus pénible de ma vie. Il n’est que 8h05 quand j’arrive à mon bureau et pourtant je suis déjà en retard, Kasperski m’attend tranquillement, la mine affable, assis devant mon bureau. La paire de Samsonite sous mes yeux et mon allure abattue doivent lui inspirer de la pitié voire de la sympathie, pensé-je en m’affalant sur ma chaise.

– Kasperski, ce week-end dans la sueur et le cambouis a achevé de me convaincre de changer certaines choses. Je souhaite tenter une expérimentation qui incarnerait notre nouvelle devise, « maximiser le débit de demandes mises en production, sous contrainte de coûts, de risques et d’intégration ». J’hésite entre plusieurs possibilités …

– Quel horizon vous donnez-vous pour atteindre vos premiers résultats ?

– Disons trois mois maximum.

– Vous êtes conscients que dans ces délais, il faut monter une équipe ad hoc et contourner le processus standard de la DSI : pré-étude, décision d’investissement, planification, cahier des charges … Sachez qu’un projet vide, c’est déjà cent vingt jours hommes et trois mois de délai.

– Vous m’avez déjà servi ce discours sur les limites à l’innovation imposées par nos diverses règlementations, Kasperski. Je suis peut-être inculte, mais pas totalement idiot. Oui, nous trouverons bien un « bocal » pour isoler une petite équipe des usages de la DSI. Reste à composer la biosphère en trouvant le qui et le quoi

– Bien. A l’issue des trois mois, en imaginant que vous soyez à même d’exposer de bons résultats, quelles personnes souhaiteriez-vous convaincre qu’il s’agit d’une méthode à généraliser progressivement ?

– Typiquement mes directeurs de département et, hors de mon périmètre, les représentants des utilisateurs qui sont nos donneurs d’ordre. Ce sont les deux catégories de responsables qui pourront impulser des changements à leurs troupes.

– En quoi un succès local, obligatoirement moins complexe que ce qu’ils gèrent au quotidien, pourrait-il constituer une référence à leurs yeux ?

– En effet, il y a un risque non nul de s’exposer aux « oui mais c’était un projet facile », « oui, mais ils n’ont pas à gérer tout l’existant, eux », « oui, mais ils n’ont pas dû se farcir la sécurité » …

– Comment pourrait-on atténuer ce risque selon vous ?

– En s’imposant le même genre de contraintes qu’eux, mais cela sera difficile dans un simple bocal …

– Ne peut-on trouver un moyen de répliquer des contraintes dans le bocal ?

– On pourrait, en réutilisant le même objet qu’un projet déjà en cours … un projet qui aurait appliqué des recettes diamétralement opposées …Attendez. Bon sang, mais c’est bien sûr, le Global CRM[1] ! Ah ah ! Cinq ans que ça dure, deux ans sans livraison, des collaborateurs désabusés, des fournisseurs qui se servent sur la bête, des utilisateurs qui baissent les bras … Je devrais en pleurer, mais au moins on peut considérer que l’on tient notre quoi, et sans doute aussi notre qui !

– Parfait. Comment allez-vous procéder ?

– Ecoutez, je vais envoyer une convocation ciblée, retrouvez-nous à 14h ici-même.

Jean-Pierre est l’ancien adjoint du directeur de programme Global CRM. Il a démissionné du poste en claquant la porte il y a deux ans. Il a tout de suite répondu à mon invitation à déjeuner et nous nous retrouvons à la cafétéria :

– Comment allez-vous Paul ? Cela fait un bail !

– Très bien, merci. J’ai décidé de me lancer dans de grands changements pour m’arracher à la morosité du quotidien. Voyez d’ailleurs mon plateau repas : impasse sur les frites, un fruit en dessert, pas de vin. Vous devez vous demander s’il s’agit bien du Paul que vous connaissiez !

– Nul doute qu’il n’en existe qu’un ! Je vous sens surtout d’humeur chafouine, vous n’auriez pas une proposition indécente à me faire par hasard ?

– Peut-être, peut-être. Mais parlons d’abord de votre expérience sur Global CRM. J’en suis resté à votre démission fracassante pour cause de « divergences d’opinion » avec la direction du programme.

– Mauvais souvenir. Je me suis battu pendant trois ans pour faire accoucher ce projet d’un minimum de fonctionnalités, le mythe du grand soir a été le plus fort. A la fin j’étais seul contre tous : l’éditeur, les conseillers, l’intégrateur. Je n’avais plus aucun allié ; il fallait réaliser un logiciel qui adresse la vente, l’avant-vente, l’après-vente, à la carte, massive, pour les gros clients, les petits clients, pour tous les produits et dans toutes les régions ! Quand le directeur a imposé une extension à l’international, cela a été la goutte d’eau qui a fait déborder le vase !

– Je vois que la plaie est encore vive…

– Cela a été très difficile. Je n’aurais jamais pensé que défendre par le bon sens les intérêts de la Générale allait à ce point m’ostraciser ! Souvent, j’avais l’impression que les moyens s’étaient substitués aux fins. L’objectif n’était plus d’aider les banquiers à servir leurs clients, l’objectif était de conserver notre gros véhicule projet, lancé à toute allure sur des murs qu’il traversait intact grâce à de savants solos de guitare exécutés lors des comités de pilotage clés…

Fascinant. Son ressentiment sera à la fois un moteur (l’avantage rage), et un inconvénient pour ce que je vais lui proposer. Il ne pourra pas s’empêcher de positionner de manière évidente l’initiative pilote contre l’énorme programme, toujours bien en orbite.

*

Cela dit je m’en veux de ne pas l’avoir défendu davantage à l’époque. Je dois lui redonner sa chance :

– Ecoutez Jean-Pierre, je me rends compte que nous tous, comme vous l’avez été, sommes victimes du tropisme bureaucratique des organisations ! Les normes servent le « plus de normes » et pas la cohésion du SI, les achats servent le « plus d’achats » et pas le rapport qualité/prix de nos produits, les représentants utilisateurs servent le « plus de cahier des charges » et pas la mise en production de fonctionnalités, et j’en passe.

– Oui, j’en ai au moins profité pour m’instruire : ce phénomène est connu sous le nom de loi de Parkinson, du nom de son auteur, qui l’a publiée dans les années 50 ! Il démontre que, compte tenu du fait qu’un gestionnaire souhaite d’abord multiplier ses subordonnés, pas ses rivaux, et que les gestionnaires se créent du travail entre eux, le total des emplois dans une bureaucratie croit de 5 à 7% par an, indépendamment de toute variation dans la quantité de travail à réaliser…

– Désolant ! Mais j’ai décidé de créer une opportunité, de démontrer que l’on peut réussir différemment. Je vous propose la direction d’un projet pilote dont le principe est de livrer en continu des demandes utilisateurs, avec l’objectif de constituer un précédent, une sorte de jurisprudence, pour le fonctionnement de la DSI.

– Rien que ça ! Mais c’est trop tard Paul, comme vous le savez, j’ai fui la DSI et j’ai trouvé un job tranquille au Marketing. Assez des batailles perdues d’avance, mes années Don Quichotte sont désormais derrière moi.

– Un moment, Jean-Pierre. OK, je vous promets surtout du sang, de la sueur et des larmes, mais l’expérimentation ne durera que trois mois, et sera directement supportée par moi. La gloire est au bout du chemin si nous y arrivons ! Je ne peux pas croire qu’un homme comme vous se satisfasse d’un boulot de technocrate !

– Elle est un peu grosse votre ficelle Paul… pffff, et qu’est-ce qui vous fait penser que je ne me sens plus utile ou que je m’ennuie ?

– Votre œil n’a brillé qu’un seul instant depuis tout à l’heure, quand j’ai prononcé le mot « projet pilote ». On ne se refait pas, Jean-Pierre…

– Vous avez peut-être raison Paul. Mais je dois réfléchir, je vous donnerai une réponse dans quelques jours.

– Je n’ai pas tout ce temps, nous démarrons demain en fait.

– Comment ça, il faut quand même que je prévienne et que je m’organise !

– C’est tout vu, je vais appeler votre patron ; il me doit un service. Quant à vos collègues, je ne vous interdirai pas de les revoir de temps en temps. Merci de votre aide Jean-Pierre.

Et d’un. Quant à mon deuxième barbare, je viens de passer le week-end avec lui. Il devrait être moins difficile à convaincre…
Un frisson de plaisir m’envahit, sensation que je n’avais plus éprouvée depuis de lointaines batailles, images fugaces, instant proustien.

*

Il est 14h30 dans mon bureau. Jérôme s’est installé sans la moindre résistance dans la fonction de responsable technique du projet, le week-end a eu au moins cela de positif. Jean-Pierre laisse libre cours à son cynisme quand il évoque GlobalCRM (« vous savez, depuis qu’on a mis en production le lot 1, on ne vend pas moins »). Kasperski est en retrait comme d’habitude. L’ambiance est chaleureuse, mais je dois maintenant mobiliser l’équipe sur l’action :

– Chers amis, pour livrer en continu, il nous faut imaginer un flux de demandes dont chacune pourrait être saluée par des « merci ! » ou des « enfin ! ».

Les visages restent interloqués, je poursuis :

– Personnellement j’ai souvent entendu les agences me demander de faciliter des opérations de transformation récurrentes : joindre deux comptes en cas de mariage, les diviser en cas de divorce, modifier le statut d’une micro-entreprise en Société Anonyme, etc.

– Intéressant, poursuit Jean-Pierre. Moi, j’ai observé qu’énormément de temps du personnel en agence était consacré à la recherche de références, qu’il s’agisse d’information clients, produits, employés, statistiques, ou de modèles de document, en vue d’effectuer une autre opération. Par exemple, pour proposer une Assurance-Vie, il faudra retrouver la référence du compte courant du client, et pouvoir répondre à sa question sur le rendement moyen constaté de ce produit. Un système de recherche unifiée « à la Google » pourrait peut-être s’avérer utile.

– Oui, mais il faudra prévoir la sécurité pour ne pas permettre à tout le monde d’accéder à tout, et imaginer un outil générique qui permette de collecter toutes les données dans les différents systèmes source, ajouté-je.

– OK, et on peut tout de suite anticiper une connexion au portail interne et prévoir un fonctionnement dégradé en mode nomade poursuit Jérôme.

Jean-Pierre l’interrompt et s’adresse directement à moi en élevant sensiblement le niveau des décibels :

– Ah non, cela ne va pas recommencer ! Je suis venu ici pour de l’action ! Je croyais que l’on devait changer de méthode, on n’est pas supposé travailler sur des plans mais sur de la livraison en continu !

– Bien sûr Jean-Pierre! Mais pour livrer en continu, il faut pouvoir modifier le logiciel aujourd’hui comme demain. On ne peut s’exonérer de prévoir un minimum les besoins futurs, et s’accorder sur des plans permet de minimiser le coût des évolutions futures, non !?

A ce moment-là, Kasperski tente de calmer le jeu :

– Ecoutez, je pense que nous avons tous le même objectif de « livrer en continu », mais nous entrevoyons toutes sortes de solutions pour y parvenir. Je vais tenter une reformulation des idées que vous avez émises.
Il prend un feutre et dessine promptement au tableau :

Le silence se fait et il commente son schéma :

– Chaque relation de droite à gauche décrit une condition nécessaire, fondée sur une hypothèse, un modèle mental. Pour livrer en continu, il est nécessaire de modifier le logiciel maintenant comme demain (les besoins). Pour Jean-Pierre, livrer vite nécessite donc de coder au plus tôt, sans plans détaillés chronophages (le pré-requis).

– Exactement, pour moi ce qui est important c’est l’équipe plus que les plans, ajoute Jean-Pierre.

– Pour Paul, il faut produire des plans qui permettent d’éviter les gros changements qui seront chronophages plus tard. La Théorie des Contraintes[2] de Elyahu Goldratt nous enseigne que dans ce type de conflit, l’une des hypothèses sous-jacentes à ces relations « est nécessaire à » est forcément fausse. Laquelle d’après vous ?

– Jérôme saisit la balle au bond : je ne connais pas cette théorie des forces contraires machin, mais je suis convaincu qu’il existe des techniques de programmation qui rendent le changement peu coûteux.

– Lesquelles ? dis-je en l’interrompant.

– Par exemple la technique qui consiste à coder autant de programmes de tests que de programmes tout court. Lorsque survient un changement qui nécessite de remanier le code, les tests automatiques permettent de garantir que ce qui marchait avant marche encore. C’est un harnais de sécurité puissant pour se lancer dans des modifications profondes en toute sécurité. A l’inverse, les anticipations planificatrices que j’ai pu voir à l’œuvre ont toutes invariablement échoué à prévoir l’imprévisible. La seule certitude, c’est que lorsque le besoin est là, il faudra livrer vite ! Je milite donc clairement pour la première hypothèse !

Pendant ce temps, Kasperski note au tableau :


Devant l’assentiment général déclenché par la tirade de Jérôme, je conclus l’échange façon grand seigneur :

– Très bien, vous m’avez convaincu. Il faut donc chercher le plus petit truc qui pourrait créer de la valeur pour les utilisateurs, puis répéter cette démarche jusqu’à obtenir un ensemble utile.

– Avoir les moyens de réaliser vite pour pouvoir décider tard … songe tout haut Jean-Pierre. J’imagine l’angoisse pour la plupart des managers frileux du SI, qui tentent de se rassurer avec des plans ultra-précis !

Kasperski l’interrompt :

– Essayez d’avoir plus de compassion que de mépris pour les gens différents de vous, Jean-Pierre, et vous découvrirez peut-être une vertu derrière ce qui ne semble être qu’un défaut.

Puis il poursuit, comme si de rien n’était :

– Devant le succès de cette première réflexion issue de la TOC, je vous en propose une autre. Il s’agit de tester la pertinence d’une innovation, et donc de tester votre idée de base. Il suffit de répondre aux trois questions suivantes :

  1. Quelle est sa force, qu’apporte-t-elle de nouveau ?
  2. Pour une entreprise qui souhaite la mettre en place, quelle limitation à ses performances permet-elle de lever ?
  3. Et enfin, quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation et qu’il faudra remettre en cause pour tirer parti de l’innovation ?

Jérôme est le plus prompt à réagir :

– Quelle est sa force, qu’apporte-t-elle de nouveau ? Il s’agit de permettre de rechercher un client, un contrat, un produit, un employé ou une statistique en une seule opération.

Jean-Pierre enchaine :

– Pour la Générale, en quoi cela conduit-il à faire contrepoids à la limitation de ses performances ? La recherche de références représente empiriquement de 10 à 30% du temps de nos dizaines de milliers d’agents, en back-office ou au contact du client. On pense pouvoir diminuer de moitié ce ratio avec un tel système.

Je conclus :

– Quelles sont les règles, tacites ou explicites, qui font que la Générale a pris l’habitude de vivre avec cette limitation ? Je vais vous dire ce que j’en pense : l’organisation en silos spécialisés bien sûr ! Pour toutes les réponses que pourrait rendre un seul moteur de recherche transverse, il existe aujourd’hui un spécialiste par catégorie : le centre d’expertise crédit pourra vous renseigner sur tous les prêts possibles, mais il ne connaît rien aux contrats d’épargne ; du reste la sécurité lui interdit de les consulter !

L’équipe s’observe tranquillement. Le but est désormais clair et partagé. Inutile d’en rajouter, la complicité s’est substituée au traditionnel contrat. Quant aux autres traditions de la Générale, chacun a pleinement conscience de ce qui est en train de se jouer : les règles du projet informatique sont enfreintes avec ma protection, mais bientôt nos travaux impacteront des règles de cloisonnement bien plus profondes … Les regards font penser à ceux de guerriers avant la bataille, à la fois enivrés et graves.

*

Il est 9h quand Jérôme rejoint la grande salle que l’on a réservée au projet. Pour une fois, tous les acteurs sont réunis dans un même lieu. Une jeune femme est là, elle fait part de son expérience avec beaucoup d’énergie et produit quelques schémas au tableau. Autour d’elle, Jean-Pierre et deux programmeurs sont assis et l’écoutent attentivement. L’ambiance semble détendue.

Après son départ, Kasperski commente :

– Dans ce qui vient d’être dit par notre amie chef d’agence, qu’est-ce qui d’après vous est le plus important pour elle ?

– Son bonus à la fin du mois ! répond un programmeur.

– Très drôle, poursuit Jean-Pierre. J’ai l’impression qu’elle nous a raconté une seule et unique histoire finalement : celle d’un salarié de la Générale, qu’il soit conseiller en agence ou expert en back-office, incapable de fournir une réponse à un client.

– Oui, dès lors que la question sort de son champ direct d’expertise, précise l’autre programmeur.

– Quel est le système qui permettrait de lever cette limitation ? demande Kasperski.

– Ben on l’a déjà dit : un moteur de recherche.

– On ne va tout de même pas indexer toute la Générale de Banque aveuglément. Qu’est-ce qui, de manière sûre, résout déjà un problème concret dans ce contexte global ? interroge Jean-Pierre.

– Ah oui, ça me revient, avance Jérôme. Le coup du conseiller en agence qui se fait insulter parce qu’incapable de connaître le détail des contrats issus de partenaires de la Générale : l’assurance du prêt ou le crédit à la consommation par exemple.

– Voila un bon point de départ, commençons donc par construire cette fonctionnalité, sans rien d’autre, propose Jean-Pierre.

– Mais, et la personnalisation par profil, l’intégration au portail d’entreprise, la sécurité ? gémit un programmeur.

– Si nous fournissons juste un système basique, tout seul, que dira la chef d’agence ? poursuit Jean-Pierre.

– Probablement « merci », enfin j’espère.

– Alors produisons déjà ça. Il sera toujours temps après d’ajouter ce que les utilisateurs nous suggéreront.

Jérôme intervient alors :

– Avant de procéder à la division habituelle des tâches, je propose d’adopter la méthode suivante : découper le logiciel en petites fonctionnalités comme « collecter les données d’assurance », « présenter un écran de recherche », « présenter un écran de résultat pour les crédits-conso » …

– Qu’est-ce qui est nouveau là-dedans ? demande un programmeur.

– Pour chacune de ces « histoires », nous avons coutume de détailler dans des modèles ce que signifie « présenter un écran de résultat ». Or souvent ces modèles ne permettent pas de traduire toute la subtilité, la complexité de la demande. Je vous propose donc de les étayer par des tests dans des cas concrets.

– Comme par exemple « étant donné un client avec un contrat X, le moteur de recherche devra donner le montant souscrit… » ?

– Plus précisément encore. Il faut être concret jusqu’au bout : « étant donné le client Martin, 27 ans, avec un contrat d’assurance crédit à 0,5% sur un montant de crédit de 300 000€, le moteur de recherche devra afficher 1 500€ ».

– Ah !

– Et ce n’est pas tout. Je voudrais écrire ces tests avant l’application elle-même, car écrire ces cas concrets nous aide à mieux comprendre et cerner le comportement attendu.

– Mais ils ne passeront pas, tes tests, puisque le code n’est pas écrit !

– Et oui ! Pas au début ! Mais c’est le jeu. Et vous verrez, tout le monde préfère passer du rouge au vert en écrivant le code qui obéit aux attendus, plutôt que l’inverse, quand les utilisateurs vous font passer du vert au rouge en s’apercevant des nombreuses erreurs et incompréhensions qui jalonnent le logiciel. En plus, le nombre de tests qui passent deviendra, vous verrez, un indicateur d’avancement très utile.

L’autre programmeur lève les yeux au ciel et poursuit :

– Si nous pouvons tester automatiquement l’application grâce à ces programmes, nous le pourrons demain, après-demain et dans dix ans non ? Dans nos méthodes traditionnelles, la charge de test est devenue le poste le plus important – et le plus dénué d’intérêt – dès que l’on fait une modification de l’application… là ce pourront être des robots automatiques …

– Son camarade ajoute : je trouve ça plutôt bien, seul un robot peut s’épanouir en passant un par un des cas d’usage et vérifier que le résultat est conforme à ce qui est décrit dans un cahier …

– Trêves de rêveries les gars ! Au boulot ! Maintenant à vous de me démontrer que le coût du test de non-régression n’augmente effectivement pas avec le temps ! conclue Jérôme.

*

Bernard, du Département Exploitation, a rejoint l’équipe après un mois de travaux. La chef d’agence a assisté à la dernière démonstration du produit en construction et souhaiterait l’utiliser dès à présent.

Bernard réfléchit :

– Ça va gueuler. Vous avez beau être malins, ce sera difficile de collecter les informations pour votre moteur de recherche dans les différents silos de l’entreprise ; chacun avec ses équipes, son planning, ses priorités.

– Qu’est-ce qui pose problème, on demande juste des extraits de leurs données ? demande Jean-Pierre

– Vous ne suivez pas les règles. Ça dérange.

– Comment peut-on s’en sortir alors ?

– Je vois deux solutions : soit être patients et effectuer vos demandes via les canaux officiels. Avec un peu de chance dans six mois vous aurez peut-être quelques fichiers pour alimenter votre moteur. Comme on ne teste qu’à la fin, il faut prévoir quelques allers-retours pour les finitions, donc disons neuf mois.

– Et la seconde option ?

– Continuer à déroger aux règles.

– Comment cela ?

– Je connais les données dont vous avez besoin. Certaines transitent déjà dans le système décisionnel, les autres transitent sur nos plates-formes d’échange avec l’extérieur. Je peux vous fabriquer vos fichiers, mais quelqu’un doit me couvrir, je peux y laisser ma peau.

– J’appelle Paul ! conclut Jean-Pierre.

*

L’appel de Jean-Pierre m’extirpe d’un comité de pilotage interminable. Quand j’entre dans la salle dédiée au projet, j’ai tout d’abord une impression de désordre, puis mon regard est attiré par le nombre important d’informations postées sur les murs. Tiens, un tableau à trois colonnes à faire/en cours/fini et des post-it indiquant les travaux dans chaque colonne … là un autre diagramme « vélocité » qui montre une courbe d’abord chaotique, puis stabilisée autour de 11 demandes par itération. Une note indique « une itération = une semaine ». Mais donc c’est le débit de demandes ! Impressionnant, ce que je souhaite mesurer à un niveau global, ils le mesurent déjà localement, tout seuls comme des grands ! Il est donc possible de généraliser ce mode pilotage à toute la DSI …

Bernard me tire de mes pensées :

– Bon alors patron, on y va, ou bien ?

– Comment ?

– Je fabrique discrètement les fichiers dont ils ont besoin oui ou non ?

– Oui, allez-y.

– Vous réalisez que cette action va invalider les investissements énormes réalisés jusqu’à aujourd’hui pour cloisonner l’information ?

– Il me semble que c’est justement cette règle que nous devons changer. Allez-y avec ma bénédiction. Dites-moi Jean-Pierre, la vélocité, vous pourriez me l’extraire de votre panneau paléolithique et la remonter dans une base de données ?

– Pff. On va déjà livrer un moteur de recherche, on verra peut-être plus tard pour tout ça chef ?! Un jour votre DSI ressemblera peut-être à la communauté GNU-Linux, mais bon en attendant …

*

Dring !

– Allo oui, Paul Boulier, qui est à l’appareil ?

– Bonjour, Sylvain Fievet, chef d’agence à Boulogne. On m’a dit qu’il existait un moteur de recherche très utile qui a été expérimenté dans une agence pilote à Levallois.

– Oui, c’est exact.

– Eh bien, je ne comprends pas pourquoi nous ne sommes pas informés. Pourquoi n’a-t-on pas accès à ce système ?

– Euh. Et bien d’habitude, nous préparons le changement, nous proposons des formations…

– Mais on s’en fout de vos formations ! J’ai vu le système, il est simple et efficace, nous le voulons, maintenant.

– OK. En fait vous êtes la douzième personne à me demander l’accès. Je vous donne l’adresse, mais ne l’éventez pas trop, nous ne sommes pas sûrs de la puissance de nos machines.

– Pffff ! Ecoutez, mon fils qui n’est pas informaticien, génère plusieurs centaines de milliers de hits quotidiens sur son site dédié à je ne sais plus quel jeu vidéo. Et c’est vous l’expert, effrayé par quelques dizaines de milliers d’utilisateurs ! Vous imaginez Google en train de me dire « attention, ne tirez pas trop sur la machine » quand je crée une nouvelle boîte au lettres ? C’est amusant comme attitude face au succès. Allez, merci quand même.

Incroyable, c’est la première fois que l’on déploie un truc que les gens veulent, sans besoin « d’accompagnement au changement ». Amusant effectivement …

[1]Customer Relationship Management : gestion de la relation client

[2]Theory Of Constraints : corpus de techniques développées par le Professeur Eliyahu Goldratt et destinées à faire triompher le bon sens au sein des systèmes complexes. Initialement centrée sur la production industrielle, elle outille désormais les raisonnements sur tout type de système de production de valeur ajoutée, d’un hôpital à une DSI …

-> Chapitre 5

« Les conneries, c’est comme les impôts, on finit toujours par les payer. »
Michel Audiard

Il est 17h30 lorsque je me rends dans le bureau de mon responsable des systèmes Internet. Je ne le trouve pas à sa place, mais un sous-responsable vient à ma rencontre, manifestement mal à l’aise. Il me raconte que le programme a été mis en production par un prestataire il y a un mois, mais que le premier gagnant n’est arrivé qu’hier. Comme le projet était fini, la prestation a été terminée, conformément à la règle.

J’interroge :

– Donc vous me dites qu’il n’y a plus personne pour réparer ce programme qui sélectionne les gagnants et envoie des messages ?

– C’est-à-dire qu’il est compliqué, il touche à d’autres programmes, j’ai commencé à réunir les différents intervenants…

– Comment ça compliqué ? Vous plaisantez ! Un programme qui sélectionne un nom et envoie un mail ?!

– En fait le programme est en deux parties puisque pour l’envoi des messages nous utilisons la plate-forme de messagerie multi-canal du Groupe. C’est un gros sponsor du projet.

– Pfff… Et quelle est la technologie là-dessous ?

– Ça dépend où, mais du côté du problème c’est en gros du XSB12 et du NET43. Autour, il y a bien sûr des plates-formes GB3, des bases DUBI8, des interface SQOP, des..

– Bien, merci, je vais dépêcher quelqu’un directement. Prévenez ce qu’il reste de vos troupes sur le terrain que quelqu’un arrive.

– Mais, il n’y a plus personne, M. Boulier, comme je vous l’ai dit ….

– C’est vrai qu’il n’y a plus un seul sachant. Alors vous pouvez partir en week-end ! Ou peut-être est-ce le moment d’organiser un comité de réflexion transverse sur la stratégie de résolution des incidents ?

Respirer. Se calmer. Il va falloir trouver des pompiers de service, mais qui ? Réfléchissons. Il y a Jérôme, un jeune trentenaire, à l’aise dans plusieurs technologies, dont celles qui nous préoccupent. Il peut agir dans tous les compartiments du jeu informatique – de l’interprétation des besoins à la mise en service de programmes – là où plusieurs de nos ressources standards sont nécessaires et doivent de plus être coordonnées.

Je l’appelle :

– Allo les pompiers ?

– Ah non Monsieur Boulier. On est en week-end là !

– Ecoutez Jérôme on a un gros problème ici. Un mailer soi-disant intelligent s’est mis à distribuer des cadeaux à tous nos clients.

– Pff. Il faut que cela arrive alors que j’ai une pinte de bière à la main. Vous ne pouviez pas appeler une autre poire ! Au fait, c’est quoi les cadeaux ?

– Le compteur est resté bloqué sur un voyage en Martinique…

– Waw ! Vous m’en offrez un si je vous tire d’affaire ?

– Vendu !

– Avec ma copine ?

– D’accord.

– J’arrive.

*

Je me tiens derrière le dos de Jérôme dans un grand open space déserté. Il a pris connaissance du problème depuis une heure, et la seule chose que je puisse faire est d’essayer de lui simplifier au maximum les choses. C’est comme dans un épisode de 24 H mais je ne suis pas Jack Bauer. Je ne comprends rien à ses manipulations sur le clavier et à l’écran.

Tout à coup Jérôme tape du poing.

– ‘Tain on n’y arrivera pas comme ça, c’est un plat de spaghetti, j’ai rarement vu ça. J’ai fait quelques modifications mais il y a des bouts du système que je ne peux pas atteindre, ni même tester d’ici. Je suis dans un environnement restreint au programme de sélection des gagnants, or il utilise tout un tas d’autres programmes comme la plate-forme de messagerie Groupe et le référentiel client central.

– Qui pourrait nous aider à atteindre les autres programmes ?

– Ben si on veut faire vite, les types de la production. Sinon vous devrez monter une « équipe transverse » qui mobilise tous les acteurs de la chaîne.

– Si j’appelle à cette heure je n’aurai que des opérateurs qui ne sauront pas aller au-delà de la procédure standard, or là on ne fait pas vraiment du standard …

– Oui c’est vrai, il faudrait joindre un gars qui connaît à peu près tout et qui a accès à tout. Bernard Gropiset vous connaissez ?

– Je ne connais que lui ! Je l’appelle.

Bip Bip Bip.

– Bon, Jérôme, il ne répond pas. J’ai laissé un message pour qu’il nous rejoigne au plus vite. Je suis sûr qu’il sera là demain à la première heure. Vous pourrez être présent également, disons vers neuf heures ?

– J’essaierai de penser aux îles … allez, à demain.

*

Samedi.

Il est 9h28 quand Jérôme pénètre dans l’open space, toujours empli de ma seule présence :

– Bernard ne devait pas venir ? dit-il.

– Il est là depuis une demi-heure, figurez-vous, et il est au téléphone sur haut-parleur.

– Salut champion ! résonne une voie sortant d’un combiné décroché. Le patron m’a dit qu’avec toi on en aurait à peine pour quelques minutes. Un test de bout en bout, une mise en production d’un programme, et hop retour dans ma campagne.

– Espérons. Pourquoi n’es-tu pas ici, avec nous, au 22e ?

– Je travaille au 2e sous-sol. Parce qu’on ne peut pas changer les programmes à distance, ni du 22e, ni de chez moi.

– Ah.

Jérôme utilise les accès de Bernard et déploie son programme modifié dans les environnements de test du référentiel client. OK, les deux systèmes ont l’air de fonctionner ensemble, un client « test23 » sera utilisé pour l’essai. Un virement de test lancé.

Maintenant la plate-forme de messagerie. Nos yeux sont rivés sur l’écran de contrôle des messages aux gagnants qui est pour l’instant vide. L’instant dure une éternité. Le virement pour le client Test23 apparaît enfin à gauche. Que va faire le programme ? Le silence règne, je retiens mon souffle en observant l’écran des gagnants. Jérôme pousse un cri. Ce n’est pas un mais deux messages qui viennent d’apparaître !

– J’étais sûr qu’ils ne nommaient pas leurs variables de la même manière dans les différents programmes que j’ai dû modifier. J’ai dû m’emmêler les pinceaux entre deux données. En même temps il n’y a pas deux programmes qui se ressemblent, à croire qu’ils ont été triturés par mille mains connectées à des cerveaux qui ne se seraient jamais parlé !

– Pas impossible, une partie de la maintenance est mutualisée dans nos usines near-shore et off-shore… suis-je obligé de reconnaître.

Me laissant abattu, Jérôme saute sur son clavier et se met à taper comme un fou, le téléphone coincé sur son épaule.

– Allo Bernard ? Marche arrière toute. Il y a un nouveau bug. 2 messages à la fois.

– Ah ben bravo le p’tit génie. Je ne te félicite pas.

– N’en rajoute pas s’il te plait.

– Je vais faire ma petite enquête dans ce plat de spaghetti de mon côté … je vous tiens au courant.

– Tu as vu, il neige !

– Sous mille tonnes de béton, on n’est pas dérangé par des visions bucoliques. Les néons néonnent toujours. Va donc bosser au lieu de contempler le paysage !

Quelques minutes plus tard :

– OK c’est bon cette fois-ci ! éructe Jérôme.

– J’active les mêmes programmes ? répond Bernard.

– Oui, les mêmes.

Cette fois la peur est palpable. Dans le système en production, on est à plus de 10 000 opérations, c’est-à-dire 10 000 voyages en Martinique, alors que l’on attendait à peine 200 gagnants, et un seul voyage. Le compteur continue de tourner sur l’écran de contrôle…
Cette fois-ci la correction fonctionne enfin. Plus de messages dans la plate-forme de test. Il ne reste plus qu’à remplacer les programmes en production.

– Bernard, ça roule. Tu peux tout passer en production !

– Go ! entend-on résonner gaiement dans le haut-parleur… Alors ?

L’écran de contrôle s’est arrêté depuis 1, 2, 3, secondes … pas de message, malgré un virement passé …
… 4, 5, 6. Nous retenons toujours notre souffle. 10 secondes, l’hémorragie semble endiguée. Enfin. Nos regards se croisent, heureux et complices.

Bravo les gars ! Je ne vous offre pas un verre qui abuserait encore de votre précieux temps de week-end. Je ferai le point avec vos responsables dès lundi. Reposez-vous bien.

*

Dimanche

J’ai mal dormi. Ce bug m’a fait cauchemarder toute la nuit. Il est à peine six heures du matin quand je décide d’allumer mon ordinateur pour tuer le temps avant le réveil du foyer. Tiens je vais faire mes comptes. Bonne nouvelle, un peu de liquidité traine sur le compte courant, j’opère un virement vers mon compte épargne.
Une vision d’horreur s’échappe alors de l’écran : « Bravo Paul, vous avez gagné notre super cagnotte, un voyage en Martinique ! ».
Je dors encore, ce n’est pas possible. Je me pince. Toujours le message à l’écran. Je vérifie mes mails. Un nouveau message de la Générale et daté d’aujourd’hui 6:13 est apparu : « Cher gagnant …».

Non !

Je ronge mon frein jusqu’à 8h30 avant d’appeler Bernard et Jérôme. Bernard est en colère, et Jérôme en piteux état, il est sorti tard hier soir…

Quand nous nous retrouvons à dix heures, je décide de réunir l’équipe au sous-sol chez Bernard pour être plus efficaces ensemble.

Jérôme a la migraine. C’est finalement Bernard qui diagnostique rapidement le problème :

– Un programme de nuit[1] qui n’a pas été modifié hier a effacé les informations gagnant/pas gagnant en mettant à jour les données client du site Internet à partir du référentiel central. Du coup notre programme de gestion du concours repart comme en quatorze, pensant qu’il n’a pas encore de gagnant.

– Mais, cela signifie que ce deuxième bug existait depuis le début ? interrogé-je.

– Le premier bug a occulté celui-ci, mais effectivement si nous n’avions pas déjà 3000 gagnants par jour, mais seulement les 200 prévus, nous recommencerions à zéro le lendemain !

– Et personne n’a jamais testé cela ?

– Ce programme se lance dans les chaînes de traitement nocturnes qui sont difficilement testables vu les volumes de données énormes à gérer… poursuit Bernard. En revanche, je peux le désactiver assez facilement.

– Ah oui ? Et demain on éteint quoi ? La comptabilité ? tance Jérôme.

Je réfléchis. Si je leur demande de réparer encore cette erreur maintenant, la dette technique va continuer à empirer : un nouveau bout de code au milieu d’un patchwork métastasé par copié/collé, et encore un programme sans test incapable de dire s’il marche ou pas. A ce rythme, mieux vaut éteindre tout ce qui ne satisfait aux critères minimaux de qualité, au lieu d’essayer de réparer désespérément l’irréparable. On verra plus tard comment réagira l’organisation.

Je lance :

– Bernard, pouvez-vous recharger les données client d’hier et éteindre ce programme de nuit ?

– Cela doit être faisable.

– Mais vous êtes fou ? s’énerve Jérôme. Vous n’imaginez pas toutes les manipulations que réalise ce programme : il recopie les nouveaux clients, les anciens, ceux qui changent de nom, de sexe ou que sais-je encore ! Si nous le neutralisons, plus rien ne fonctionnera !

– Pour l’instant, ce programme contient des fonctionnalités cachées qui ne font partie d’aucun cahier des charges. Pour celles que vous citez, ce sera peut-être l’occasion de secouer les gens en vue d’améliorer la testabilité du système. Jusqu’à ce week-end je pensais que la dette technique était due à l’obsolescence technologique, mais je m’aperçois que c’est plutôt le manque de clarté et de testabilité des programmes qui tue notre productivité.

– Effectivement, les technologies changent mais les programmes restent. Dans la vie rien ne se crée, tout se transforme ; mais dans le SI, rien ne se transforme, tout se garde, philosophe Bernard.

– C’est vrai qu’au cours du week-end, nous avons finalement passé 99% de notre temps à comprendre des systèmes obscurs et à tester avec les moyens du bord… renchérit Jérôme.

Je conclue, paradoxalement enthousiaste :

– Imaginez ce que serait la vie dans notre Système d’Information si « clarté » et « testabilité » devenaient la norme !

Au bout de quelques heures tout est enfin réglé. Enfin, « réglé », rien n’est réglé. Le bug s’est arrêté, mais il est toujours là, et nous avons désactivé une chaîne de traitement qui avait très probablement son utilité. Tout commence en fait.

En rentrant chez moi je réfléchis et me demande pourquoi il y a dans notre organisation tant de responsables encadrant des ressources obéissantes et spécialisées, et si peu de Jérôme ou de Bernard. Peut-être parce qu’ils gagnent moins qu’un manager ? Ou que leurs perspectives de carrière sont moins intéressantes ? Difficile à accepter, mais c’est sans doute parce que nous ne valorisons pas les profils de ce type « contremaître » que nous n’en avons pas. Le système est polarisé sur le management, faire est donc devenu sale…

Quand j’introduis la clé dans la serrure de mon domicile, il est presque onze heures du soir. Tout est silencieux. Je monte lentement les marches du grand escalier. Un rai de lumière échappe de la chambre de Luc, mon aîné, à qui j’ai pourtant interdit de veiller pour mieux se concentrer sur ses études, jusqu’à présent peu brillantes. J’ouvre délicatement la porte pour m’apercevoir qu’il dort en fait profondément, un bras pendant hors du lit, et a simplement oublié d’éteindre sa lampe de chevet. Tandis que je m’approche de l’interrupteur, un détail attire mon attention. L’aiguille d’une seringue dépasse de sous le lit, et à ses côtés traine une petite cuillère noircie. Saisi de panique, j’attrape son poignet pour prendre son pouls. Dieu soit loué, son cœur bat. Le mien en revanche s’est arrêté. Que s’est-il passé ? Comment n’ai-je rien vu venir ? Mais quel aveugle ! Et tout de me revenir en mémoire : les déjeuners où il était si « bizarre », son mutisme de plus en plus fréquent, ses absences …

Mais il y a des choses qui vont changer ici ! D’abord lui parler, et obtenir la vérité : depuis combien de temps ça dure ? D’où vient la drogue, d’où vient l’argent ? Où en est-il avec ça ? Ensuite, checkup médical discret à la clinique de Jean-Hugues mon beau-frère et cure de désintoxication dans la foulée. Au fait, préparer la communication pour la famille… Bon, je descends me servir un Whisky pour me calmer et mieux réfléchir.

3 heures du matin. Je remonte dans la chambre de Luc, qui dort toujours aussi profondément.

Mais au fond que sais-je de lui vraiment ? Depuis sa naissance, je pars au travail avant qu’il ne se réveille, et n’en rentre qu’après son coucher. Nous avons dû avoir au mieux une demi-douzaine de moments de complicité ces dix dernières années, et lorsqu’exceptionnellement nous avons une discussion, je m’évertue à le bombarder de jugements définitifs sur ce qu’il devrait faire de sa vie ! Lui ai-je jamais demandé ce qu’il désirait, lui ? Lui ai-je jamais demandé ce qui le bloquait dans ses objectifs ? Lui ai-je jamais fait confiance ? Au fond c’est moi son overdose. Je fais partie du problème, tout autant que lui.
Il faut absolument que je change quelque chose. Il faut que l’on se parle enfin. Il faut que je sois là tous les jours avant 18 heures dorénavant. Un point c’est tout. Un point c’est tout nom de Dieu ! Je ne peux donc plus micro-piloter mes équipes, je dois leur faire confiance, déléguer vraiment. Je vais seulement les aider à définir leurs buts, mais plus leurs moyens. Piloter par la vision, plus par le manuel de procédures.

Je fonds en larmes. Luc, papa revient.

[1]Programme dit « batch », de traitement par lot.

-> Chapitre 4

« Tous les modèles sont faux, mais certains peuvent être utiles. »
Edward Deming

Cette nouvelle dialectique du but et des contraintes me perturbe au plus haut point. Pourquoi donc la division d’un but en sous-buts semble-t-elle échouer systématiquement ? Toute ma scolarité d’ingénieur, je l’ai placée sous le rationalisme de Descartes : tout problème peut se décomposer en sous-problèmes indépendants, toute cause produit des effets et il existe des causes premières, des lois immuables qui expliquent la réalité …Cette nouvelle confrontation avec un écosystème humain trop contingent me renvoie soudain des vagues de nostalgie. Je me trouve replongé dans l’univers mathématique de ma jeunesse, où tout était plus simple, plus beau, où je croyais qu’existait LA solution.

Peut-être ai-je besoin de me référer à un nouveau maître ? J’appelle Kasperski. Une fois arrivé dans mon bureau, l’énergumène ne juge pas utile de s’excuser de sa récente disparition. Je n’ose pas faire allusion à cet épisode, et compose le numéro de Secrotas.

– Jean-Louis Secrotas ? C’est Paul Boulier de la Générale.

– Bonjour Monsieur Boulier, comment allez-vous ?

– Très bien, merci, et vous-même. Je suis en compagnie d’un collaborateur, M. Kasperski, qui m’a aidé à répondre à vos questions.

– Excellent, à quelles réponses êtes-vous parvenus ?

– Le but de la DSI est de maximiser le débit de demandes mises en production, sous contrainte de coûts, de risques et d’intégration.

– Fantastique ! C’est extrêmement clair. Je ne dis pas cela pour vous être agréable. Utilisé comme leitmotiv auprès de vos collaborateurs, cela pourra effectivement guider chacune de leurs décisions.

– Merci Jean-Louis ! Je peux vous appeler Jean-Louis n’est-ce pas ? Cependant nous ne pouvons en rester là, un slogan ne suffit pas. Je fais quoi maintenant ?

– Avez-vous le sentiment que la DSI atteint son but tel que vous l’exprimez ?

– Non.

– Quelles sont les causes majeures qui l’en empêchent ?

– A cette question pour une fois j’ai tellement de réponses possibles que je ne sais laquelle choisir : peur de régressions sur ce qui marche déjà si on accélère les évolutions, circuit de décision d’investissement très long, vieillissement du patrimoine informatique, différences de productivité entre équipes …

– Avez-vous une carte du Système d’Information qui nous permette de visualiser les facteurs clés de succès pour atteindre votre but ?

– Bien sûr ! dis-je fièrement, en tentant de me connecter à l’Intranet « Cartographies du SI ».

– Contient-elle des informations qui permettent de mesurer la valeur pour le métier, le débit, le coût, ou la sécurité ?

– Euh … non, pas directement, c’est une cartographie. Mais elle contient un recensement exhaustif de nos systèmes et de leurs relations, c’est déjà bien utile.

– Pas vraiment pour ce qui nous concerne.

– J’ai aussi la carte de notre dernier schéma directeur … elle fait apparaître très distinctement les blocs fonctionnels, les référentiels de données …

– Un schéma directeur n’est qu’une carte virtuelle, Paul, un modèle qu’on aspire à faire émerger de la réalité, mais pas la réalité. On ne sait d’ailleurs pas à un instant t si la réalité projetée sera meilleure. Au fond, qui peut le savoir ?

– Mais qu’avez-vous en tête alors, Jean-Louis ?

– Je peux vous proposer un petit exercice qui devrait vous aider : dresser une nouvelle carte du SI qui apporte un niveau d’information utile pour atteindre le but tel que vous l’avez exprimé. Je vous envoie à l’instant la légende de cette carte par email.

Effectivement, trois messages surgissent sur mon ordinateur.
Secrotas commence son exposé :

« Je vous propose de mesurer trois métriques pour chaque application du Système d’Information.
La première est l’actif. J’entends par là la valeur qu’a le système du point de vue de ses utilisateurs. Cette métrique est rarement mesurée car on peut tergiverser des années sur ce que vaut un système : vaut-il la somme de ce qu’il a coûté, le coût de son arrêt pendant 3 jours, la perte d’une image de marque s’il tombe ? C’est du reste souvent pour cela que l’on ne mesure que les coûts. Pour mesurer l’actif, osez faire fi de l’abondante littérature engendrée par le thème du capital immatériel. Utilisez une méthode simple, fondée sur une seule question : « que ferions-nous sans ce système ? ». Les utilisateurs vous répondront alors soit qu’ils doivent sortir d’un marché – ce serait par exemple le cas pour un commerçant électronique qui perdrait son site Web – soit qu’ils doivent remplacer le système par des petites mains et de la bureautique – un système comptable pourra toujours être remplacé par un tableur et des dizaines d’opérateurs.

Au final vous obtiendrez un chiffre approximatif en euro. Cette valeur donnera la surface de nos applications, comme l’explique mon premier message :

La deuxième métrique est le coût total de l’application. J’insiste sur le total. Il s’agit d’évaluer l’économie annuelle que réaliserait la Générale si elle supprimait ce système. Cette économie prend sa source jusque dans les activités de construction et d’exploitation, souvent séparées dans des budgets différents – par exemple x euros d’études et de développement et y euros de machines, licences logiciels, heures d’astreinte, etc. Vous utiliserez une teinte allant du clair au foncé pour matérialiser ce coût en pourcentage de la valeur. Plus un actif est clair, plus son rapport valeur/coût est intéressant, plus un actif est sombre moins il est utile à l’entreprise ; et un actif gris coûte autant qu’il rapporte :

La troisième et dernière métrique est le passif de chaque système, c’est-à-dire la dépense qui serait nécessaire pour ramener l’application vers des normes de productivité cohérentes avec votre but. Là encore, descendez sur le terrain, et posez simplement la question « quel serait le niveau d’investissement nécessaire pour que cette application revienne à l’état de l’art de la productivité ? ». Vos collaborateurs pourront chercher à évaluer la dette technique accumulée avec le temps, dette à l’origine des coûts et des risques d’aujourd’hui : strates accumulées sans jamais nettoyer le fond, données en doublons, testabilité difficile, obsolescence technique. Ils réfléchiront alors à un projet de remaniement qui permette par exemple d’homogénéiser, de factoriser, d’ajouter des tests automatiques ou de mettre à jour la technologie. Pour finir, vous représenterez le coût ainsi évalué de ce projet en pourcentage du coût total calculé précédemment : 10% un contour fin, 100% une croute épaisse.

Paul, d’après vous à quoi ressemblerait la carte du Système d’Information selon cette légende ? » conclut-il.

Je réfléchis un moment. Il m’énerve avec ses bulles de savons et ses chiffres « à la louche », j’ai l’habitude des vrais chiffres moi ! J’essaie de rester calme. Je commence à lister les éléments qui me viennent à l’esprit : beaucoup d’applications dont les métiers pourraient difficilement se passer, bon rapport qualité-prix dans l’ensemble, passif limité grâce aux programmes d’urbanisation et de réécritures entrepris sous mon autorité, quelques moutons noirs le long de la route…

Je me lance dans un brouillon de dessin, mais déjà Secrotas prend congé poliment, et nous invite à le solliciter dès que nous aurons les premières esquisses.

Kasperski m’aide à formaliser mes intuitions. Nous les consignons dans une première carte.

Tout à coup, avant que je ne le lui suggère, il me demande de combien de temps il dispose pour mener un premier niveau d’enquête.

Je lui donne quinze jours et ma bénédiction…

*

Il est plus de 19h quand Kasperski entre dans mon bureau en brandissant des papiers avec une moue gênée.

Le quotidien qui m’a envahi ces dernières semaines m’a presque fait oublier la carte, et surtout mon ultimatum.

« Paul, j’ai rencontré plus de vingt équipes, interviewé en groupe les métiers et les informaticiens, et consolidé le résultat dans cette carte » dit-il en dépliant son ouvrage.

Et d’ajouter :
– C’est plus noir et crouté que prévu …

Il a réussi à me mettre immédiatement en colère. Je l’invective :

– Je dépense une part colossale du budget en contrôle qualité, en normes et procédures, en standards d’architecture, en composants mutualisés et vous me représentez le SI comme une sorte de décharge pleine de boules puantes, où la moitié des logiciels seraient pourris et devraient être remplacés !

Puis de m’excuser :

– Désolé Kasperski, vous n’y êtes pour rien. Les délais de livraison s’allongent, les clients n’ont pas ce à quoi ils s’attendent, et l’informatique coûte de plus en plus cher. Maintenant en plus, avec ce type de schéma, il m’est impossible de défendre son rapport qualité/prix ! Mais il reste un élément qui m’échappe : nos collaborateurs sont vaillants et compétents, ils ont tous des missions précises, qui participent d’une manière ou d’une autre à la réalisation du but, qu’ils soient développeurs, exploitants, acheteurs, architectes …

– On peut prendre l’hypothèse que chaque département fonctionne de manière optimisée, et que le grand horloger, vous en l’occurrence, n’êtes pas assez compétent pour coordonner le tout. Mais je ne pense pas que ce soit cela la bonne approche. La DSI n’est pas une horloge, ce serait plutôt un ensemble de cercles, vicieux ou vertueux, entrant en résonance les uns avec les autres : l’optimum de l’un peut nuire à l’optimum de l’ensemble.

– Hum. Appelons Secrotas, je veux son avis.

Bientôt sa voix résonne dans le haut-parleur :

– …. En effet, d’une manière générale produire de la valeur ajoutée nécessite de coordonner les efforts, de synchroniser les nombreuses ressources de l’entreprise : développement, marketing, vente, production, finance…Ce débit de valeur ajoutée se trouve à la merci du maillon le plus faible de la chaîne. Vous êtes d’accord avec moi Paul ?

– Oui. Mais pouvons-nous dérouler le raisonnement sur un exemple d’optimisation locale, celle des prix de revient par exemple.

– En voulant optimiser les coûts on néglige souvent l’importance de certaines ressources contraintes, qui pèsent sur l’ensemble de la chaîne en ce qu’elles en dictent le débit maximal. Par exemple, les achats décident de s’adresser à un fournisseur de roulements à billes moins cher mais livrant moins vite, avec comme résultat final d’assécher la contrainte, c’est-à-dire le poste d’assemblage du train avant, qui utilise ces roulements. La comptabilité analytique va saluer une diminution des prix de revient (et l’acheteur obtiendra sa prime), mais le débit de voitures aura diminué, ainsi que l’efficacité de l’entreprise au regard de son but. Sur ce poste goulet, il vaut mieux choisir un fournisseur plus cher mais plus fiable.

– Je sais. Lorsque nos achats font un but à part entière de la diminution du prix de revient des prestataires informatiques, ils peuvent s’opposer à l’objectif principal qui est de maximiser le débit de demandes mises en production… Comme disait un de mes amis CIO « If you pay peanuts, you get monkeys ».

– Cela peut même aller plus loin dans les effets pervers. Dans l’industrie, le pilotage par les prix de revient encourage à faire des stocks – or plus personne aujourd’hui ne souhaite faire des stocks, c’est-à-dire immobiliser du capital. En effet, quand les ventes vont mal, il convient de baisser l’activité pour s’aligner sur la demande. Mais alors, les coûts unitaires grimpent, puisqu’une grande partie de ces coûts n’est pas variable mais fixe : on ne supprime pas les gens ou les machines comme ça, même si on ne les utilise pas ! Pour préserver l’optimum local des « prix de revient », on va donc surproduire en période de sous-activité !

– J’imagine que tout cela a des raisons historiques. La méthode devait être pertinente au début du siècle, quand l’essentiel des coûts étaient variables, y compris le travail, payé à la pièce jusqu’au début du XXe siècle. Aujourd’hui, c’est souvent l’inverse, l’essentiel des coûts est fixe – les salaires sont payés à l’heure, pas à la pièce – mais la méthode de comptabilité analytique n’a pas évolué.

– Exactement, comme quoi il est temps d’évoluer !

J’enrage de n’avoir pas réfléchi davantage auparavant en ces termes, car tout m’apparaît de manière limpide à présent : non seulement il y a les achats qui diminuent les coûts unitaires de main d’œuvre au détriment de la qualité des logiciels produits, mais il y a aussi les représentants des utilisateurs qui tentent de « bien » cadrer la création de logiciel en accumulant les demandes métier dans des cahiers des charges qui – sous couvert d’exhaustivité – ne distinguent plus le nécessaire du superflu ; les architectes « simplifient » le SI en créant des guichets normatifs où s’empilent les demandes des projets ; les délais sont encore allongés, et au final voient le jour dans la douleur des monstres parfois adaptés mais toujours inadaptables…

Et tout ceci n’accorde pas une grande valeur au temps ! Alors que la maîtrise du temps est la vertu qui peut entraîner toutes les autres : les coûts bien sûr par effet mécanique, mais aussi la qualité, car pour livrer vite en toute sécurité il faut l’augmenter…
Et si on arrêtait la quête de systèmes adaptés à tout pour se consacrer à bâtir des systèmes adaptables !

Le téléphone sonne, interrompant mes pensées :

– Oui, j’écoute

– Ici Pichot de la Direction Commerciale. Vous êtes ailleurs ou en vacances Paul ?

– Pardon ?

– Vous avez dans votre boîte aux lettres un message que vous auriez peut-être dû lire avec attention …

Je me précipite sur mon ordinateur, Pichot est le Directeur Commercial et je ne l’ai jamais eu au téléphone pour autre chose que de gros soucis …

Effectivement un message dix fois transféré, répondu et re-transféré avec désormais une vingtaine de destinataires appartenant à quatre niveaux hiérarchiques vient de me parvenir :

From: Stéphane Pichot
Subject: Tr : Tr : Re : Alerte, bug sur le site Internet suite mise en production version 3.12Paul, faites quelque chose, vite.
SP.
>
> … vous vous foutez de ma gueule !!! On est en train d’offrir un voyage en
> Martinique à tous les mecs qui font un virement sur notre site bordel !!!
> …
>
>>
>>… on a développé la nouvelle fonctionnalité de super pactole pour le
>> 100 000e virement …
>> … depuis qu’on a atteint les 100 000, chaque nouveau virement indique
>> « vous avez gagné le pactole », est-ce normal car il n’était pas spécifié
>> que l’on doive remettre le compteur à zéro ? …
>>

Je tourne la tête pour regarder la nouvelle carte d’état major : la bulle « site Internet particulier » est noire, avec une énorme croute rouge. Je sens mon sang se glacer. D’après la carte, cela signifie que la dette technique est monstrueuse, donc que la correction prendra du temps, et que l’on a toute chance de déclencher d’autres bugs …

« Kasperski, je gère l’urgence ce soir et cette nuit. Pour le reste, on commence lundi. 8h dans mon bureau. Excellent week-end. »

-> Chapitre 3

« Je vois des ordinateurs partout, sauf dans les statistiques [de productivité] »
– Robert Solow (1987)

Paris, 3 janvier 2008

Sept heure trente du matin et je suis déjà à mon bureau, au trente septième étage du siège de la Générale de Banque. L’instant est calme et rien ne vient troubler le dépilage consciencieux de ma boîte aux lettres électronique. Tiens, une enquête du service Qualité & Développement Durable : Merci de remplir ce questionnaire sur la qualité de vie au travail et nous le retourner avant le 15 janvier. Attends, je rêve ou ils me demandent de ressaisir toutes mes informations personnelles ? Ils ne pouvaient pas les demander aux Ressources Humaines ? Et voila encore cinq minutes de perdues à ressaisir ma fonction, mon bureau, mes trois enfants… Elle est où, la qualité, une simple extraction de données du système RH aurait suffi à économiser 500 000 minutes à la boîte ! Mille jours.homme de perdus !

Je me présente, je m’appelle Paul Boulier. J’occupe le poste de Directeur des Systèmes d’Information depuis bientôt quatre ans. L’informatique dans l’entreprise, c’est moi. Sept mille personnes sous mes ordres, 1 milliard d’euros, une lourde responsabilité que j’ai finalement endossée, quinze ans après mon arrivée à la Générale.
Et moi, ils vont m’entendre au service Qualité & Développement Durable !

Huit heures. Henri de Montleau, le Directeur Général, pénètre inopinément dans mon bureau et me sert des banalités d’usage. Cet homme tout en réserve s’intéresse soudainement à mes projets de vacances, va jusqu’à me faire part des siens, j’attends la suite. L’animal n’est pas coutumier des amabilités matinales et en plus je le soupçonne de me mépriser. Ce ton affable me rend doublement nerveux…

– La crise nous plombe, mais sachez-le, cher Paul, c’est de l’ordre de l’incident conjoncturel. Le vrai problème, c’est que nos actionnaires sont las de voir la Générale sur les troisième ou cinquième marches des podiums : troisième banque d’affaires sur les dérivés de crédit, cinquième banque à réseau d’Europe … On ne fait plus rêver personne, à commencer par nos clients qui sont de moins en moins fidèles. Le conseil d’administration réclame de l’ex-cel-lence. Et qui est en bonne place sur les marches du podium des principaux goulets ? C’est vous.

– Quoi !? Moi ? Les systèmes d’information, un goulet ? Les bras m’en tombent ! Que juge-t-on au juste ? Etes-vous conscients du travail réalisé par mes équipes ? Nous ne sommes pas de vulgaires techniciens sur qui l’on peut jeter unilatéralement l’opprobre !

– Pensez-vous, Paul, nous sommes tous le technicien, voire le pion d’un autre, moi y compris … D’ailleurs, il n’y a pas que les actionnaires, mes directeurs ne cessent de se plaindre de votre absence de réactivité et de vos coûts exorbitants. Encore heureux que le système fonctionne à peu près régulièrement, sinon je n’aurais pas été en mesure de prendre votre défense comme j’ai dû le faire récemment…

– Vous m’en voyez reconnaissant, répliqué-je en me demandant s’il était vraiment sincère mais sans oser l’interroger sur les circonstances. Personne n’a jamais vu Henri de Montleau défendre qui que ce soit.

– Je vous donne six mois pour redresser la barre et me présenter des résultats significatifs. Au-delà, je serai obligé de prendre des mesures d’externalisation drastiques…

Il me laisse encaisser avant de poursuivre :

– Comme je ne pense pas que l’on puisse changer de recette sans changer de cuisinier, je vous suggère de prendre contact avec ce consultant qui est un expert en accompagnement au changement. Voici sa carte.

– « Jean-Louis Secrotas, value through IT » indique la carte. (encore du consulting à deux dollars, où est-il allé me trouver ce nouveau bouffon ?).

*

– Monsieur Secrotas ?

– Oui.

– Paul Boulier, Directeur des Systèmes d’Information de la Générale de Banque, vous pouvez m’accorder quelques minutes ?

– Oui bien sûr, enchanté.

– Henri de Montleau, mon Directeur, vous a recommandé pour nous aider à améliorer la performance de la DSI. J’aurais aimé connaître votre mode opératoire pour ce type de mission.

– Il dépend essentiellement de vous.

– Oui bien entendu, mais par exemple comment compteriez-vous démarrer une telle tâche si je vous la confiais ?

– Quel est le problème avec la DSI ?

– On la juge coûteuse et peu réactive.

– Vous me donnez deux problèmes, je n’en demandais qu’un. Quel est le principal problème ?

Je m’arrête un instant, surpris par la question autant que par le ton.

– Nous sommes trop chers, finis-je par lâcher.

– Etes-vous sûr que vos clients préfèreraient disposer d’une DSI moins chère à réactivité égale plutôt que d’une DSI plus réactive à coût égal ?

Je ne m’étais jamais posé la question sous cette forme. Impossible d’y répondre sans un minimum de réflexion. Heureusement l’autre enchaîne :

– Je vais vous poser la question différemment : quel est d’après vous le but de la DSI ?

Mon légendaire aplomb se trouve maintenant totalement pris en défaut. Je me vois incapable de répondre avec discernement. Tout se brouille, les objectifs assignés à mes différents départements dansent bruyamment dans ma tête : diminuer les coûts, homogénéiser les technologies, réutiliser des systèmes, mutualiser des infrastructures, garantir des temps de réponse corrects, externaliser tout ce qui peut l’être, rédiger des cahiers des charges de qualité, simplifier le SI, … A quoi tout ceci nous mène-t-il ?

Cette conversation devient risquée. Cet individu est dangereux, il rapporte probablement à Montleau, et tout ce que je vais lui dire pourra être retenu contre moi. Je dois reprendre l’ascendant :

– Je comprends en effet votre approche Monsieur Secrotas : triptyque classique coûts/qualité/délais, Six Sigma, Cobit, CMMi …. Je regrette, je ne peux m’attarder au téléphone, j’ai une obligation. Ce serait un plaisir de vous rencontrer en compagnie de mes équipes, seriez-vous disponible sur Paris dans les jours qui viennent ?

– Non malheureusement, pas dans l’immédiat.

– Bien, je … euh… très bien, je vous rappelle bientôt. Merci encore pour … cette conversation.

Il me salue poliment, pendant que je parviens à dissimuler mon désarroi et ma colère. Puis je décroche une nouvelle fois le combiné :

– Hélène ? Annulez tous mes rendez-vous de la journée. Je ne veux pas être dérangé.

Reprenons le fil. Quel est le BUT de la DSI ? Impossible de voir clair. Je dois me résoudre à demander de l’aide. Surtout pas à mes directeurs, ils pourraient profiter de cet aveu de faiblesse. Et si j’appelais Jean-Daniel, mon copain de promo à la Direction des Risques !

– Jean-Daniel ? C’est Paul. Tu vas bien ?

– Ca va, je me remets doucement des fêtes. J’ai démarré mon sevrage d’escargots pralinés et mon médecin m’a conseillé de ne plus manger que de l’eau minérale pendant les six prochains mois …

– Dis donc, toi qui t’y connais bien en informatique, peut-être pourras-tu m’aider. Si on t’interrogeait sur le but de la DSI, et si tu n’avais droit qu’à une phrase, tu l’exprimerais comment ?

– C’est marrant, il y a un consultant sur le projet StopJunkBonds qui est venu poser la même question à l’équipe il y a à peine un mois ! D’ailleurs c’est quelqu’un de chez toi, un prestataire. Il s’appelle Kasperski.

– Ah, connais pas. Et alors ?

– Pour le but de la DSI j’avoue que tu me prends au dépourvu. En revanche ce type a réalisé un boulot remarquable. En quelques minutes il a fait éclater le conflit qui minait le projet depuis plusieurs mois. Et tout ça avec des questions enfantines. Au bilan, mon chef de projet et l’informaticien qui s’étripaient en décembre sont alignés comme des i sur un but commun, et le projet avance enfin. Tu devrais le rencontrer, c’est peut-être le plus simple …

– Tu as raison, merci de l’information.

Peu de temps après, Kasperski pénètre dans mon bureau. Un type bizarre. De ces faciès qu’on n’oublie pas. Je l’accueille néanmoins avec bienveillance :

– Asseyez-vous, merci d’avoir répondu si vite à ma demande.

– Je suis payé pour répondre aux demandes d’aide.

– Celle-ci va vous paraître paradoxale venant de moi, j’attends donc de vous la discrétion qui sied à ce genre d’entretien. On m’a dit que vous aviez mené avec succès une confrontation sur la finalité d’un projet à la Direction des Risques, c’est exact ?

– C’est exact.

– Vous connaissez la DSI et ses multiples objectifs : rationaliser les infrastructures, diminuer les coûts de prestations, mutualiser des systèmes et j’en passe. Mais pourriez-vous m’aider à synthétiser ce que doit être la finalité globale de la DSI ?

– Maintenant ?

– Oui, maintenant, réponds-je sèchement.

– Très bien. Je peux vous demander ce qu’attendent les clients de la DSI ?

– Ils veulent des coûts bas et de la réactivité.

– Je crois qu’ils se plaignent effectivement des coûts élevés et du manque de réactivité. Mais cela ne nous donne pas forcément tout ce qu’ils souhaitent.

– C’est vrai. Ils veulent également de la sécurité, c’est-à-dire que le système fonctionne tout le temps et ne soit pas perturbé par des maladresses ou des malveillances.

– C’est tout ?

J’hésite un instant avant de poursuivre :

– Ils veulent aussi que le système soit intégré, interopérable, c’est-à-dire qu’il offre un continuum d’informations, que vous naviguiez dans les applications commerciales, celles du back-office ou dans les outils de synthèse, sans ruptures d’ergonomie, sans ressaisies laborieuses ni données contradictoires. Tiens d’ailleurs pas plus tard que ce matin nous avons eu un exemple de mauvaise intégration …

– Le message de la Direction de la Qualité ?

– Je vois que vous saisissez mon point.

Je conclus :

– Donc le but du système est d’être peu coûteux, réactif, sécurisé et intégré. En somme, si l’on imagine la sécurité et l’intégration comme deux facteurs de qualité, nous retrouvons le classique triptyque coûts/qualité/délais connu des industriels. Je crois qu’on a fait le tour, merci de votre aide, cela a été bref mais efficace !

– Attendez un instant. Il ne peut y avoir qu’un seul but, pas quatre.

– Pourquoi ?

– Si vous indiquez quatre directions, il y a fort à parier que vos troupes seront confrontées à des conflits entre ces objectifs : plus de sécurité ici impliquera moins rapide et moins bon marché, plus vite là s’opposera à plus intégré au reste du système… Il est nécessaire de vraiment distinguer un but, et d’adresser les autres points comme des contraintes.

– Les bons managers savent déterminer eux-mêmes un compromis coût/qualité/délais ! Ne les sous-estimez pas en les prenant pour plus bêtes qu’ils ne sont, Kasperski !

– Bêtes ? J’aurais dit tiraillés plutôt. Vous savez, j’étais présent lors du choix de la méthode d’émission du message de la Direction Qualité. Ils ont bien entendu demandé aux RH de leur fournir un accès au fichier des employés, de manière à pré-remplir le formulaire. Mais l’informatique des RH leur a annoncé au minimum deux mois pour réaliser cette intégration, ce n’était ni dans leurs plannings, ni dans leurs priorités, ni conforme à la politique de sécurité en vigueur. A l’autre bout de la chaîne, le Directeur de la Qualité hurlait environ deux fois par jour pour obtenir son publipostage. Mais peut-être que le chef de projet chargé du mailing était bête après tout …

– Hum, c’est intéressant. Et donc, quelle méthode proposez-vous pour différencier ces quatre objectifs potentiellement contradictoires ?

– Projetons-nous dans un hypothétique futur où vous doublez un des facteurs, les autres restants constants. Imaginons ensuite la satisfaction attendue des clients.

Nous voilà revenus à la même question que Secrotas pensé-je… Cette fois-ci je ne tente plus d’esquive et dresse rapidement un tableau :

Ecrire me fit l’effet d’un choc.

Intuitivement, j’ai focalisé sur les coûts mais je m’aperçois bien que je n’aurai pas droit aux lauriers, tant que les demandes des métiers continueront à mettre plusieurs mois (voire dizaines de mois) à sortir. Diminuer les coûts ne peut être le but.

Quant aux deux derniers points, sécurité et intégration, pas de doute non plus. On n’agit sur aucun des deux griefs qui résonnent encore dans ma tête, telle une sentence prononcée par le procureur de Montleau : « absence de réactivité, coûts exorbitants ».

Quel dommage d’ailleurs, c’est là que je réalise à quel point ces deux facteurs, intégration et sécurité, font partie des lubies auxquelles je suis le plus attaché. J’adore faire la pédagogie du nécessaire « urbanisme du Système d’Information », essentiel à l’interopérabilité, et je peux être fasciné par tel constructeur me vantant les mérites d’une machine incassable secourue aux quatre coins du globe…

Kasperski est resté silencieux pendant mes divagations intérieures. Je reprends en me tournant vers lui :

– Si je suis votre raisonnement, le but de la DSI est d’augmenter la réactivité, sous contrainte de coûts, de risques et d’intégration.

– Allons plus avant. Qu’est-ce qui se cache derrière la réactivité ? Quelle grandeur devra augmenter ou diminuer ?

Je réfléchis :

– Euh… il y aura plus de mises en production réussies ?

– Vous en êtes à combien aujourd’hui ?

– Cela dépend des applications du système, je dirais entre une à deux par an et par application.

– Que se passe-t-il si vous doublez ce chiffre ? Vu des clients, la réactivité augmente-t-elle vraiment ?

– Ben bien sûr, les applications seraient mises à jour tous les trois mois !

– Oui, mais ce n’est pas exactement ma question. Est-ce que dans ces conditions, les demandes de vos utilisateurs seraient prises en compte plus rapidement ?

– Mais c’est ce que je viens de vous dire, je ne me fais pas bien comprendre ?

– Très bien, si vous en êtes convaincu, c’est donc cet objectif qu’il faut maximiser. Je dois maintenant vous quitter, mais je suis à votre disposition pour poursuivre cet entretien une autre fois. A bientôt.

Il quitte mon bureau impassible, et me laisse interdit. J’ai du être un peu trop péremptoire… Que voulait-il me faire comprendre avec ces demandes utilisateurs ? En tout cas, il a réussi à me faire douter le bougre ! Allez, une fois n’est pas coutume, je décide de descendre « à la soute » pour mieux comprendre. Apparemment ce gars-là tient sa pertinence de son rapport avec les deux plans de la DSI, celui des décisions et celui des opérations. Or je dois le concéder, ni moi ni aucun membre de mon entourage ne fréquentons réellement le second plan depuis de nombreuses années…

*

Le chef de projet est quasi au garde à vous devant moi, il transpire. La conversation a pourtant commencé tranquillement, j’ai juste demandé pourquoi on ne livrait pas tous les trois mois. Là il m’a expliqué que notre processus standard imposait aux utilisateurs de décrire leurs besoins dans un recueil, le cahier des charges, et qu’ensuite l’informatique créait ou achetait un système adapté à ces exigences. Comme il faut en moyenne plus de trois mois pour écrire un cahier des charges, il n’a d’abord pas compris ma question, puis a réagi :

– Ah oui je vois ! Ce que vous voulez, Monsieur Boulier, c’est que pendant qu’un cahier des charges est écrit, nous mettions en place le système en trois mois, et passions au cahier des charges suivant, c’est ça ?

– Exactement. Comme cela, nous mettrions en production un nouveau logiciel amélioré tous les trois mois.

– Le problème c’est que pour trois mois de cahier des charges, nous mettons environ cinq mois à livrer un logiciel, puis quatre mois à le tester et à corriger les erreurs avec les utilisateurs. D’ailleurs, c’est toujours la guerre en fin de projet pour distinguer les erreurs « de leur fait » car non prévues au cahier des charges, des erreurs « de notre fait » dues à une mauvaise interprétation du document.

– Et pourquoi mettez-vous autant de temps à coder ? Pourquoi générez-vous tant d’erreurs ? Tout cela ne donne pas une grande impression de performance !

– Mais les cahiers des charges ne peuvent pas être toujours clairs ou complets, on découvre de nouveaux besoins en cours de route, et il faut sans arrêt prendre en compte de nouveaux cas tordus… Faire plus vite est juste impossible ! Demandez plutôt aux représentants des utilisateurs de faire des cahiers des charges moins épais, par exemple en découpant leur besoin en petites demandes.

– Me voila bien avancé, en gros c’est la faute des autres.

– Ben oui, ils sont rétifs à ce mode de fonctionnement car ils rechignent à tester plus fréquemment, ce qui serait obligatoire si l’on traitait de plus petites demandes. Et pourtant ce travail ingrat doit impérativement être fait, d’autant plus que parfois corriger une anomalie en crée de nouvelles à d’autres endroits, il faut être très vigilant !

– Je vois…

*

– Kasperski, je ne vois pas comment on peut améliorer la réactivité. J’ai rencontré hier des chefs de projet et ils tiennent tous le même discours : aller plus vite est impossible : il y a l’épaisseur des cahiers des charges, et les tests nécessaires avant les mises en production des applications sont un enfer chronophage.

– Ils ont raison.

– Vous pensez vraiment que mon Directeur Général va apprécier cette réponse ?!

Pour la première fois, j’observe un sourire sur le visage habituellement impassible de Kasperski. Son ton a changé :

– Ecoutez Paul, tout ceci nous apprend que les règles en place – le processus dit « industriel » : les cahiers des charges épais, les équipes spécialisées entre experts métier et experts techniques, les tests effectués à la main – sont un horizon indépassable pour vos collaborateurs. Ils ne peuvent imaginer un système qui fasse fi de ces règles quasi-séculaires. Or ces règles doivent être changées si l’on veut obtenir des résultats disruptifs sur la productivité. Il vous revient de repousser l’horizon en proposant de nouvelles règles…

– Je vous en prie, poursuivez. Vous savez depuis le début où vous voulez m’emmener !

– Ce n’est pas dans mes habitudes de souffler une solution, mais puisque vous insistez. Je dirai que vos chefs de projet vous ont donné la bonne idée : désépaissir les cahiers de charges. C’est-à-dire faire en sorte que les exigences des métiers soient un flux de demandes permanent et non plus de gros sacs de demandes sporadiques. L’industrie a opéré cette transition depuis les années 50 : production tirée, lean management, one-piece-flow … mais paradoxalement peu dans le monde du service, et encore moins dans celui des services informatique.

Pour masquer mon admiration devant la simplicité et le bon sens de ce concept, je lance, feignant la vanité :

– Oui mais vous savez très bien que l’industrie informatique est bien plus en avance sur ces ploucs plein de cambouis, nous manipulons de la Haute Technologie nous !

Nous rions tous les deux, complices. Ce type me plait finalement, j’abonde :

– En somme, il suffirait d’aligner les demandes unitaires sur une finalité claire comme « permettre la vente indirecte du produit X », « maximiser le taux de conversion sur notre site », « diminuer de 20% le temps de production des états comptables » pour que régulièrement, N demandes traitées permettent de mettre en production un ensemble cohérent, utile pour la société. Reste à traiter le goulet des tests qui demeure un problème malgré tout…

– Nous traiterons les moyens plus tard, revenons à nos indicateurs. Pour que la satisfaction des utilisateurs augmente, c’est-à-dire que la réactivité qu’ils ressentent augmente, quelle grandeur devra donc augmenter ou diminuer ?

– Simple ! Le délai entre une demande du métier et sa mise en production devra diminuer.

– Est-ce tout ? Si vous réalisez n’importe quelle demande en moins d’une journée, mais que vous n’êtes capable de produire que trois cent demandes par an, le but est-il atteint ?

– Non effectivement, nous traitons chaque année plus de mille projets qui contiennent chacun de nombreuses demandes unitaires. Je vois où vous voulez en venir. Vous me rappelez mes cours de mécanique des fluides… le délai n’est que la moitié du problème, le nombre de demande dans une période donnée doit aussi augmenter. Dit autrement, le débit de demandes doit aussi être maximisé.

Je rends le feutre pour illustrer ma pensée au tableau :

– Aujourd’hui notre performance est un long tuyau de faible section, demain, elle devra être une énorme pièce de monnaie la plus plate possible !

– Exact, et il faudra aussi colmater les fuites du tuyau, c’est-à-dire éviter la production de bugs ou de fonctionnalités inutilisées !

Je reste pensif et surpris par mon propre engouement. Tout ceci est bien sympathique, mais si l’on n’a pas réussi à maximiser le nombre de demandes mises en production jusqu’à maintenant, il doit bien y avoir une raison. Les tests bien sûr, mais est-ce bien ce que demandent les utilisateurs ? Si l’on met régulièrement de nouvelles fonctionnalités à disposition, comment gérer le changement permanent ? Comment préserver la sécurité du système s’il change tout le temps ?

Quand je me retourne pour l’interroger, Kasperski a disparu…

-> Chapitre 2

L'informatique Conviviale

« Je vois des ordinateurs partout, sauf dans les statistiques [de productivité] » – Robert Solow (1987)

L’entreprise a grandi. Avec elle le nombre d’équipes qui la compose. La multiplication des Divisions, Départements et Directions a permis de réussir la croissance, pendant que la spécialisation de certains dans les Ressources Humaines, les Finances ou l’Informatique a permis la mutualisation de moyens, porteuse de réductions des coûts.

Cependant à la Générale de Banque les recettes stagnent, la profitabilité baisse de manière structurelle, et avec elle la satisfaction et la loyauté des clients. Paul, Directeur des Systèmes d’Information se retrouve en première ligne. A son guichet, les demandes s’accumulent, souvent antagonistes, et les délais de réponse ne cessent de s’allonger. l’informatique est devenue le goulet d’étranglement de toute l’entreprise.

Mais au fond, l’informatique n’est que le miroir de l’organisation, elle-même pétrie par son histoire, ses conflits et ses mythes. Les informaticiens s’y sont traditionnellement constitués en forteresse de spécialistes, comme d’autres experts, traders, comptables ou juristes.

Alors Paul veut réussir l’impossible : fluidifier la production de logiciel. Le succès de la DSI va-t-il entraîner celui de toute l’entreprise ? Peut-être que d’autres changements profonds seront aussi nécessaires.

Le système entreprise est maintenant contraint par d’autres facteurs. La DSI n’est plus en cause, mais d’autres bouc-émissaires émergent : les départements transverses – RH, finances, achats, méthodes – font toujours exploser les frais généraux sans pour autant améliorer l’efficience. Dans ce contexte, la méfiance est la règle et le cloisonnement son corollaire. L’innovation est vécue comme un acte de piraterie du système, et ne génère que des conflits… Comment alors réussir à faire évoluer les relations entre départements transverses et communautés d’opérationnels ? Comment passer de la méfiance à la confiance ? De l’éternelle lutte entre progressistes et conservateurs à l’amélioration continue de tous ?

Architecture, organisation, agilité, lean, théorie des contraintes, cloud computing … plongez dans cette fiction-réalité pour alimenter votre vision sur l’amélioration continue de l’entreprise par l’informatique et actionner vous-même le changement dès demain matin.

*

« Je vois des ordinateurs nulle-part, sauf dans les statistiques » – M. Le Président (2012)

-> Chapitre 1

L’Informatique Conviviale n’est pas le roman d’une seule personne. Mes remerciements à Laurent Avignon, Christophe Thibaut et Pascale Sauvage, ainsi qu’à tous mes autres camarades d’aventure pour leur aide inestimable : Vincent Biot, Xavier Boileau, Eric Biernat, Alain Buzzacaro, Mathieu Gandin, Emmanuel Gaillot, José Gramdi, Ismaël Héry, Yannick Martel, Eric Pantera, Olivier Pizzato.

Enfin, ma profonde gratitude à Ivan Illich, auteur de La Convivialité, pour avoir inspiré cette vision d’une informatique (enfin) au service de l’homme.