L'informatique Conviviale

« Il est plus sûr d’être craint que d’être aimé. »
Nicolas Machiavel

Je vous passe Monsieur le Président …

– Bonjour, que me vaut votre appel ?

– La Banque est en retard, cela risque de prendre plus de temps que prévu Monsieur le Président…

– Vous plaisantez, j’espère ! Vous savez ce qu’il pourrait nous en coûter d’être en retard … Du reste la Banque pourrait aussitôt devenir le goulet d’étranglement de toute la démarche non ?

– N’exagérons rien …

– Je n’ai pas envie de courir ce risque. Si cela ne va pas assez vite, c’est que votre agent du changement est le goulet. Ce n’est pas à vous que je vais apprendre à discerner une contrainte ! Appliquez vos théories, s’il vous plaît ! Mobilisez plus de monde !

– Malheureusement la contrainte principale qui pèse désormais sur l’organisation est le désalignement chronique du Comité de Direction, dès qu’il est question de l’innovation. Il existe un conflit permanent autour des arbitrages de type « Investir pour le long terme ou réussir le court terme ? » ou « Innover par les grands plans ou par le soutien aux initiatives individuelles ? » Démultiplier notre action ailleurs n’est pas la meilleure des solutions.

– Si vous le dites ! Il me semble que ce conflit entre légitimistes et légalistes ne date pas d’hier. Alors appliquez vos théories comme vous le voulez, mais obtenez les résultats que vous m’avez promis.

– Je ferai de mon mieux Monsieur le Président.

*

Il est midi dans le grand amphithéâtre que j’ai réservé pour la présentation de la réorganisation imaginée avec Moustier, Béranchon et Lefebvre. Nous avons réuni une assemblée bigarrée, composée à la fois de responsables et d’opérationnels de la DSI. Secrotas et Kasperski sont également présents, car leur aide est précieuse dans ce type de réunion où la résistance va nécessairement se manifester.

Grâce à la carte d’état major qui synthétise de manière évidente nos douleurs et nos fiertés, j’expose les principes de notre nouvelle stratégie : équipes produit intégrant les études et la production, cycles courts, amélioration continue. L’assistance semble apprécier le paradoxe selon lequel pour faire de grandes choses, il faut en réussir de petites en quantité, dès lors qu’elles sont alignées sur un but explicite.

J’explique en substance que nous ne souhaitons pas basculer de manière brutale dans ce modèle, ce serait trop risqué. Le « peut-être mieux » ne peut se substituer d’un coup à ce qui marche aujourd’hui, même mal.

Je présente donc le périmètre retenu à ce stade : deux directions Produits sont créées, une pour la Finance et l’autre pour la Direction Commerciale. Cette dernière devra gérer la partie du patrimoine informatique destinée aux forces commerciales en agence, ainsi qu’aux clients en direct, ce qui inclue donc notre fameux site Web « plus jamais ça ». Les personnels des Etudes et de la Production concernés seront déplacés dans chacune des nouvelles directions.

Une personne de l’assistance me lance, irritée :

– Vous aurez beau réunir les gens, si les achats de machines, les installations physiques ou les interconnexions passent toujours par la Production qui détient le reste du Système d’Information, vous ne tirerez aucun bénéfice de votre réorganisation ! Vous vous retrouverez face à un guichet mutualisé dont la priorité n’est pas forcément d’accélérer votre débit…

– C’est tout à fait exact, c’est pourquoi nous allons « désimbriquer » ces systèmes du reste et les remettre entre les mains des équipes produit, auxquelles seront intégralement transférées les moyens et la responsabilité d’exploitation.

– Mais cela va coûter une fortune ! Tout un tas de machines sont mutualisées !

– Ce n’est pas parce que nous nous échinons à mutualiser tout ce qui ressemble à un ordinateur depuis trente ans que c’est la meilleure façon de faire aujourd’hui. Cela s’appelle une ornière ! Il faut savoir en sortir ! Mais je vous l’accorde, plus un choix est ancien, plus il est difficile d’en faire le deuil.

– Et comment comptez-vous vous y prendre ?

– Moustier intervient : nous n’allons pas reproduire les mêmes environnements physiques en dupliquant toutes ces infrastructures, ce serait un investissement trop important effectivement. Nous allons louer des capacités de traitement et de stockage sécurisé à un ou plusieurs partenaires de confiance.

– Et comment des centres d’exploitation « éclatés » peuvent-ils fonctionner de concert ?

Lefebvre prend le micro, avec un air visiblement satisfait :

– Il me semble que personne ne se plaint des applications composites qui sont aujourd’hui la norme sur Internet : Google Maps est d’ailleurs utilisé chez nous pour tous les services géolocalisés, et on n’a pas demandé à Google d’installer ses serveurs dans nos locaux, à ma connaissance !

– Moustier renchérit : je ne vois pas d’obstacle majeur à ce que nous réussissions de la même façon avec nos centres de calcul. Nous devrons bien sûr standardiser les contrats d’interconnexion entre les futures plaques produit, notamment du point de vue de la sécurité. Chaque plaque produit sera une forteresse responsable de sa protection vis-à-vis des autres forteresses de la maison, et des partenaires extérieurs.

– OK pourquoi pas, mais en externalisant la gestion des machines à des fournisseurs, vous allez disqualifier de nombreux personnels ! J’imagine que ces marchands de cloud computing vous ont fait miroiter de bien belles promesses…

Ce syndicaliste dont le ton est limite insidieux commence vraiment à m’énerver, je boue intérieurement. Très maître de ses moyens, Moustier poursuit :

– Oui, certains métiers tels que nous les connaissons aujourd’hui vont devenir inutiles. Mais notre plan de transformation a pour contrainte de préserver l’emploi. C’est une des raisons pour lesquelles nous souhaitons avancer progressivement et non pas brutalement. Au sein de l’équipe de Direction, j’ai d’ailleurs pris la charge de gérer la transition des employés concernés vers nos nouveaux métiers : gestion de fournisseur, supervision de processus métier, programmation système, tests d’infrastructure automatisés …

Moustier enchaîne sur sa dialectique des petites « oreilles », qui poussent comme autant de nouvelles compétences acquises dans une équipe pluridisciplinaire. On voit qu’il est passionné par le sujet. Je ne doute pas une seconde de ses succès à venir.

Tout à coup, alors que les remous commencent enfin à s’apaiser, Secrotas prend la parole :

– En quoi pensez-vous que les bons résultats obtenus avec vos méthodes agiles sont à la fois pérennes et généralisables aux autres processus de la DSI, comme l’exploitation ou la cohésion du SI à long terme ?

Mais qu’est-ce qui lui prend ? N’est-ce pas assez difficile de convaincre ce public pour juger utile d’ajouter à la controverse ? Il est malade ! Mais Lefebvre répond tranquillement :

– Les démarches agiles ont permit de fluidifier la production de logiciel au niveau des départements Etudes de la DSI. Ce faisant, elles ont déplacé le goulet d’étranglement vers les phases amont – recueil de besoins, budgétisation, planification, et études d’architecture – et les phases aval – intégration au SI, tests et mise en production. L’optimisation globale du système nécessite bien entendu d’attaquer ces deux types de contraintes.

– Béranchon ajoute : l’autonomie budgétaire et les cycles courts qui permettent de prioriser en permanence les demandes vont clairement réduire les contraintes de la phase amont ; nous pouvons maintenant nous lancer sans tout prévoir…

– Moustier enchaîne : quand à la phase aval, si nous ne l’améliorons pas, inutile d’optimiser le débit de demandes. Si les équipes d’exploitation ne peuvent mettre en production au même rythme que la réalisation, le logiciel finira en stock intermédiaire devant le guichet : « en attente d’intégration » ou « en attente de test » …

Réponses manifestement insuffisantes pour Secrotas, qui semble toujours d’humeur provocatrice :

– Mais pourquoi la production deviendrait-elle la contrainte ?

– Moustier reprend, toujours calme : tout simplement par repli sur son optimum à elle, c’est-à-dire garantir la sécurité du fonctionnement, sous peine de gros ennuis ! De plus, peu d’investissements ont été réalisés pour garantir la testabilité automatique des infrastructures. Pour faire face à un nouveau logiciel arrivant d’une équipe « agile », il faut allouer une force de travail importante et réaliser une campagne d’intégration et de tests manuels souvent très lourde.

– En quoi la nouvelle organisation s’attaque-t-elle à cette contrainte ? poursuit Secrotas.

Cette fois c’est moi qui réponds :

– Nos schémas organisationnels Direction des Etudes/Direction de la Production sont hérités d’un temps où matériels, logiciels et réseaux étaient des ressources extrêmement coûteuses, donc à mutualiser absolument. Aujourd’hui, des technologies comme le cloud computing réalisent un vieux rêve, celui de disposer d’une puissance informatique à la demande, à faible coût. En utilisant cette technologie pour remettre en cause le cloisonnement Etudes et Production, c’est-à-dire en transférant la responsabilité d’exploitation à des équipes produit autonomes, nous pouvons exiger une diminution du temps et du coût d’un passage sécurisé en production, et obtenir un gain global dans la DSI.

– Et Moustier de compléter : cette stratégie nécessite de revisiter nos schémas organisationnels, comme Paul l’a expliqué. Utiliser le cloud computing sans remettre en cause ces règles serait tout simplement inutile… Une fois les équipes produit responsabilisées, à elles de déterminer les meilleurs moyens pour obtenir des résultats comme ceux de Google, qui mettent en production sur des milliers de machine plusieurs fois par semaine sans stress ni week-end homérique : tests automatisés, automates de mise à jour, support de plusieurs versions, et j’en passe.

Secrotas sourit :

– Vous avez répondu à ma première question. Je m’interroge également sur la pérennité de votre démarche. Qu’est-ce qui vous fait penser que dans quelques années vos standards de pionniers ne vont pas se transformer en nouvelles pesanteurs ? N’y-a-t-il pas un risque que la priorité devienne de faire toujours plus de tests, plutôt que de traiter plus de demandes ? Que l’important soit de raccourcir toujours plus les cycles, quelles qu’en soient les conséquences ? C’est ce qui se passe en général, n’est-ce pas, le tropisme bureaucratique, qui pousse à se polariser sur ce qui justifie son action plutôt que sur ses résultats …

L’attaque est frontale, il faut que je réagisse bien :

– Effectivement, seule une discipline d’amélioration continue peut nous permettre d’éviter ce type d’écueils, en imposant l’évolution permanente du standard. Mais qu’avons-nous fait finalement avec l’agile ? Nous avons réuni une équipe et créé les conditions de son engagement : autonomie, responsabilité et pluri-compétences. Nous avons fait le pari de la confiance. En lui fixant un but et pas les moyens de l’atteindre, l’équipe s’est naturellement améliorée.

– Kasperski se décide à sortir de son mutisme : oui, nous sommes un peu les M. Jourdain de l’amélioration continue, nous en faisions sans le savoir … Ces deux principes, ajoutés à la recherche des causes de gaspillage, sont les piliers du lean management, une discipline industrielle que l’on suit chez Toyota depuis les années 50 …

Il n’en reste pas là et exhibe, sûr de son effet, un vieux prospectus jauni extrait prudemment de son cartable :

Il commente :

– Au chapitre des gaspillages évidents, il y a le fait que 45% des fonctionnalités proposées dans nos systèmes ne sont jamais utilisées… ! Sans oublier les études qui partent à la benne, les campagnes de tests bêtement répétées, la dette technique qui s’accumule …

Secrotas intervient :

– Je comprends deux des piliers, mais pas tout à fait le dernier : « s’améliorer en continu ». Chacun doit faire évoluer ses propres standards, très bien. Mais comment harmoniser les bonnes pratiques ? 1000 foyers d’efficacité ne font pas un tout cohérent !

Etonné par cette question, je ne trouve pas mes mots instantanément. Lefebvre assure :

– Dans un monde où l’on se différencie par des résultats objectifs – tels que l’actif, le passif, le coût total, le débit de demandes, le nombre d’incidents -, les comportements vis-à-vis des standards changent ! L’ego entre toujours en jeu, mais les responsables adhèrent plus volontiers à ce qui marche. Ils veulent imiter les bonnes idées de leurs homologues pour obtenir encore plus de résultats, et s’en différencier au final.

Je complète, emporté par la verve de mon ancien directeur de l’architecture (que j’ai du mal à reconnaître) :

– C’est le paradoxe, ce « chaos » vu de l’extérieur est en réalité ultra-discipliné. En réservant du temps long au sein de chaque équipe produit, les standards se diffusent et s’améliorent. La norme n’est plus un territoire fermé, mais un actif ouvert : plan de secours, multi-versions, testabilité, interopérabilité, … tout le monde a le droit, voire le devoir, de l’améliorer.

Secrotas affiche son air ironique :

– J’ai l’impression que tout votre système repose sur ces nouveaux indicateurs « d’ordre 1 ». En dehors des coûts qui sont mesurables, pensez-vous que la valeur d’un système, son débit de demandes ou son taux d’incident puissent être réellement objectifs ?

– Vous voulez rire, c’est vous-même qui en avez parlé le premier !

– J’ai peut-être eu tort …

– Puisque vous insistez ! Oui, la mesure de la valeur est plus délicate que celle des coûts. La valeur est multidimensionnelle : elle désigne l’utile, le beau, le positif pour la marque, pour le moral, pour la productivité, pour les risques… Son évaluation est donc forcément approximative, dépendante du contexte et réalisée a posteriori. Nul modèle ne peut donc prétendre la définir de manière exhaustive, la valeur est toujours le fruit d’un consensus. Que valent par exemple trois retombées presse ou un nombre de défauts de paiement qui diminue ? Aux acteurs concernés d’en discuter.

– Au final, qu’est-ce qui permet d’éviter que le consensus sur la valeur repose sur népotisme et petites ententes ?

– Hum, bonne question. C’est un système qui repose sur la confiance, laquelle peut en effet être brisée. Néanmoins il encourage un cercle vertueux d’introspection, et d’amélioration mesurée. Plus les pratiques s’améliorent, plus la confiance s’installe, et plus l’introspection devient possible, au service de l’amélioration des pratiques. Si des équipes ne jouent pas le jeu, cela se verra.

– Quel dispositif anti-erreur, si je me réfère à une pratique que j’aperçois dans votre mémo Lean, peut-il aider à détecter une mesure erronée de la valeur ?

– Voyons. Le meilleur garde-fou, c’est le bon sens. On peut dire que les abus surviennent quand le bon sens ne triomphe plus. Par exemple, une équipe a un bon débit, mais ses clients ne sont « paradoxalement » pas satisfaits. Conflit sur la mesure. Mais nous pouvons traiter ces conflits comme une opportunité de s’améliorer. Au lieu de les fuir ou de rechercher des boucs émissaires, la résolution des conflits fait partie du cercle vertueux.

– Il faut faire tourner une machine à détecter et à gérer les conflits, en somme, conclut Secrotas, pensif. C’est très intéressant, mais de l’ordre de l’acte de foi à ce stade. Ecoutez, si votre nouvelle organisation permet la réussite d’un projet transverse aux deux nouvelles Directions, je pense que nous pourrons tous dire que vos théories passent vraiment à l’échelle…

Béranchon, visiblement soulagé que l’interrogatoire se termine, lance :

– Il me semble que le chantier Bâle III est un bon candidat : nouvelles informations à collecter côté Réseau commercial, nouveaux reportings comptables et prudentiels côté Finances ; et tout le monde qui s’apprête à vivre le pénible marathon habituel du grand programme…

– Mais vous êtes fous, pas sur un truc aussi gros ! grogne discrètement Lefebvre.

– Je l’interromps : cher ami, les petits trucs, on les a déjà réussis ! Alors on y va.

– Mais nous prenons un risque énorme !

– Finalement, pas plus que lors de nos premières expérimentations, que nous ne faisons qu’élargir. Comme précédemment, concentrons-nous sur la création des équipes et des conditions de leur engagement. D’abord qui, après quoi.

*

Prospectus trouvé dans une salle de réunion (tout tâché de café) :

L’objectif de cet atelier sera de faire émerger une équipe pluridisciplinaire alignée sur la vision d’un produit, qu’elle aura définie en toute liberté.

Les activités seront animées par des coachs et suivront le déroulé suivant :

– Rechercher auprès de chacun les facteurs de succès qu’il a observés au cours de sa vie professionnelle (méthode Appreciative Inquiry). Permettra de :

• créer des connexions entre les membres de l’équipe
• créer un environnement bienveillant d’écoute et de partage propice à la créativité

– Collecter et sélectionner toutes les idées d’usage ou de produits qui pourraient générer des résultats utiles pour la mission qui nous est confiée : fluidifier l’innovation, sous contrainte de risques et de coût (méthode Card Storming)

• Faire émerger un produit

– Aligner la vision qu’a l’équipe du produit (méthode Product Box)

• Sceller cette vision sur un objet concret, une boîte en carton (!)
• Etre capable de communiquer cette vision à l’extérieur

Une boîte « Une Informatique conviviale pour la Direction Commerciale » traine sur un coin de table :

*

Quelques mois plus tard. Je descends en visite dans la division produit Commerce. Les équipes ont investi deux étages entiers et je profite d’un attroupement devant un panneau pour prendre quelques nouvelles :

– Alors, ça avance ? La transition se déroule bien ? Les portes claquent moins qu’il y a deux mois ?

Mon interlocuteur me répond, goguenard :

– Je vais vous dire, comme nous le rappelle le cynique Dr House – on a la culture qu’on peut -, le cycle d’acceptation du deuil se déroule toujours en 5 phases : déni, colère, marchandage, dépression et enfin acceptation.

– Quel rapport entre notre manière d’accepter la mort et la gestion du changement ?

– Le changement, c’est à dire l’acceptation d’une nouvelle idée, suit le même processus. Lorsque vous devez changer : je n’écris plus de code sans tests, je ne mens plus, je cherche à comprendre les gens plus qu’à les convaincre, ou tout autre changement par rapport à une attitude antérieure, vous subissez ce douloureux processus de deuil de vieux choix.

– Kasperski, que je n’avais pas remarqué, poursuit : la vitesse de ce processus dépend des individus mais aussi des groupes dans lesquels ils évoluent. Elle peut aller de la seconde à plusieurs années … Toutes les dynamiques d’amélioration continue – agile, lean ou TOC – sont contraintes par ce processus. C’est finalement la contrainte des contraintes…

– L’avantage c’est qu’à la différence de la mort, qui n’arrive qu’une fois, on peut changer de nombreuses fois, et par là-même progresser ! Etant donné que l’on réalise plusieurs changements par mois, la plupart des gens ici ont aussi diminué ce temps de cycle !
(rires)

– C’est quoi ce tableau au mur « Journal PDCA » ?

– L’historique des améliorations en cours ou que nous avons réalisées au travers de cycles courts Plan Do Check Act.

– Ah ! La fameuse roue de Deming ! Combien de temps dure un cycle en moyenne ?

– Entre une semaine et trois mois, au-delà cela ne marche pas. Cette méthode nous impose de remonter aux causes profondes des problèmes puis de nous entendre sur une idée de contre-mesure, et surtout sur les résultats que nous en attendons. A chaque petit pas, une prédiction.

J’observe avec attention le tableau affiché au mur :

Je commente :
– La vraie vie quoi … D’en haut tout paraît simple : des fonctionnalités, des données… et puis nous le savons tous, le diable est dans les détails.

– Tout à fait. On ne peut plus maîtriser un système aussi complexe par une analyse linéaire, cartésienne, qui tente de découper le problème en sous-problèmes.

Je vois que nous avons suivi le même itinéraire de pensée :

– Je m’en suis rendu compte il y a quelques mois quand j’ai arrêté le projet d’urbanisme, détaillé et découpé en différents niveaux d’architecture, au profit de la carte d’état major unique et partagée entre tous les acteurs.

– Vous avez bien fait ! C’est bien entendu sur ce fond de carte que nous sommes en train de représenter les principaux patterns de nos systèmes.

– Patterns ?

– Oui, les éléments structurants et récurrents qui les caractérisent : sécurisé en tout sauf/rien sauf, tests automatisés/tests manuels, référentiel public/référentiel privé, transactionnel et batch/transactionnel ou batch, etc.

– Et vous pensez qu’ils répondent mieux à vos analyses d’impact que toute autre information exhaustive ?

– Oui, ils permettent de lever des alertes sur la faisabilité très rapidement. Ce n’est pas magique, mais c’est à ce jour le meilleur outil que l’on ait trouvé pour réaliser des prédictions de délais de livraison.

– Et bien je n’aurai qu’un mot, bravo ! Continuez !

– Il n’est pas question de s’arrêter… S’il y a une seule chose de stable désormais, c’est bien que l’on s’améliore en continu !

-> Chapitre 9