Articles Tagués ‘cloud computing’

Des Systèmes d’Information en amélioration continue

Aussi simple de s’en servir que d’y contribuer

Tout ce qui n’est pas explicitement interdit est autorisé, mais tracé et réversible

Supprimez votre propre poste, vous êtes promu

Publicités

« 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

« The nation that will insist on drawing a broad line of demarcation between the fighting man and the thinking man is liable to find its fighting done by fools and its thinking done by cowards. »
Sir William Butler

Je me sens détendu comme jamais depuis longtemps. Ces vacances m’ont fait le plus grand bien, mais surtout cette reconnaissance du comité exécutif me galvanise. Obtenir un tel soutien du DG pour une action aussi structurelle est une première pour moi. Non que je n’aie jamais reçu de lettre de mission de mes supérieurs, mais celle-ci tient en une ligne, mûrement réfléchie et comprise entre nous : maximiser le débit de demandes mises en production, sous contrainte de coûts, de risques et d’intégration. Nous l’avons même simplifiée ensemble avec Montleau : fluidifier l’innovation sous contrainte de coûts et de sécurité ; nous avons en effet considéré que l’on améliorait aussi l’intégration avec des fonctionnalités comme : synchroniser deux référentiels, fusionner des fonctions en doublon, homogénéiser une série d’écrans, etc. Saint-Exupéry a dit : « La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer », et j’ai le sentiment d’en comprendre le sens pour la première fois de ma vie. Mes précédents contrats de direction tenaient dans plusieurs classeurs, ce qui est, j’en ai la conviction maintenant, la marque d’une forme de lâcheté mêlée à l’impuissance.

Il s’agit désormais de faire partager le but à l’ensemble du personnel de la DSI. Je pourrais diffuser un message par courriel ou afficher des posters sur les murs, mais je doute qu’une telle approche en surface puisse modifier des comportements profondément ancrés. Ce n’est pas le nième rappel de mon médecin sur mon cholestérol qui va modifier mes habitudes de consommation de whisky. Il faudrait que j’en discute avec plusieurs personnes, que l’on confronte les points de vue, que l’on m’accompagne dans une transition progressive…ou pas d’ailleurs. On ne change que les gens qui le veulent, et avec eux, pas loin d’eux, me confiait Secrotas l’autre jour.

Je vais donc agir par cercles concentriques. Convaincre le comité de direction de la DSI, puis laisser les membres agir en effet boule de neige. La structure principale de mon organisation est un triptyque : les Etudes qui développent, la Production qui maintient en conditions opérationnelles, et les fonctions de Support et de contrôle qui garantissent les standards d’architecture, de méthode ou d’outils.

Béranchon aux Etudes est un ingénieur comme moi, sérieux, analytique. Moustier à la Production est un homme d’origine plus modeste qui a gravi les échelons en partant de la base, grande gueule, souvent sur la défensive.
Enfin Lefebvre est aux fonctions transverses : architecture, méthodes, achat, contrôle de gestion. C’est un fin politique, bardé de diplômes, jeune loup plein d’ambition. Tous sont déjà au courant des différents succès obtenus ces derniers mois, mais aucun ne s’est réellement positionné pour ou contre. Il est temps de les embarquer.

*

– Merci d’avoir pu réserver ce créneau d’une demi-journée dans vos agendas, je sais que cela n’a pas dû être facile. Je vous ai réunis pour discuter ensemble de l’avenir de la DSI. Bonne nouvelle, la DG soutient la proposition de polariser l’informatique sur un but unique et global : fluidifier l’innovation sous contrainte de coûts et de sécurité.

Ils regardent en silence le paper board sur lequel j’ai écrit la devise puis Béranchon se lance :

– Fluidifier l’innovation, cela signifie lancer plus de projets ? Vous ne pensez pas que l’on en gère déjà trop ?

– Sauf votre respect, l’interrompt Moustier, il faut veiller aux priorités. Personne ne vous tiendra rigueur de projets business qui arrivent en retard – la preuve, vous êtes encore là – en revanche si le système d’information tombe en panne, si, pour reprendre votre jargon, la « sécurité » fait défaut, vous ne serez plus là pour en parler …

– Il n’est question ni d’architecture ni de contrôle de l’entropie dans cette devise ! Le système d’information doit être correctement architecturé, il doit être homogène si nous voulons maîtriser les coûts, la sécurité et faire en sorte que les différentes parties intéropèrent, achève Lefebvre.

Et me voilà jouant le rôle de Secrotas et Kasperski dans une partie de maïeutique avec mes trois directeurs. Les gros projets versus le flux de demandes continu, la sécurité et les normes comme contraintes et non comme fin, l’interopérabilité comme fonctionnalité à valeur ajoutée … La noirceur et l’épaisseur des croûtes sur la nouvelle carte d’état-major font beaucoup pour les convaincre. Au bout de deux heures, chacun ayant compris que l’importance de son action n’est pas remise en cause par ces nouveaux objectifs, la devise est comprise et acceptée. Je sais bien que l’on est encore loin d’un changement de politique à ce stade. Chassez le naturel, il reviendra au galop.
Si je les laisse maintenant, ils reviendront vite aux fondamentaux qui dirigent encore leur quotidien – comme moi récemment avec Jean-Pierre sur le coup des soi-disant nécessaires plans adaptés à un objectif lointain alors qu’un logiciel adaptable est bien plus efficace ! Que ce soient la spécialisation des tâches, les contrats sur plans détaillés et figés, les penseurs séparés des combattants, le mythe du jour/homme iso-productif, sans compter tous ceux qui ne me reviennent pas immédiatement… Comment éviter que ces nouveaux concepts ne se diluent dans les vielles habitudes ?

Tout à coup une coupure de presse me revient à l’esprit. Cette histoire d’amélioration continue chez Toyota, avec des résultats si différents entre unités Japonaises et unités Françaises. Un point fondamental émergeait : la différence de pacte social. Au Japon, lorsqu’une série d’améliorations conduit à supprimer son propre poste, on est promu, et surtout pas remercié. En France, à l’inverse, après plusieurs mois d’amélioration sur le site de Valenciennes, l’entreprise fait un constat de surproduction, et décide… de supprimer les excédents ! Bilan : ce sont ceux qui ont progressé qui sont sanctionnés ! Au Japon, en cas de licenciement, c’est le Directeur qui doit personnellement expliquer à chaque famille pourquoi il a échoué à conserver ses salariés. Forcément, cela donne à penser.

Je partage ce point avec eux pour les rassurer et pour qu’ils pactisent avec leurs troupes dans cet esprit, en espérant rendre ainsi les discussions plus ouvertes. Maintenant sonne l’heure de la dispersion :

– Bien, il s’est dit beaucoup de choses aujourd’hui, peut-être est-il temps de laisser reposer. Je vous laisse réfléchir aux schémas de fonctionnement nécessaires pour organiser nos troupes dans ce nouvel objectif. Ne raisonnez pas en statique, je pressens que nous devrons modifier l’organisation. Faites abstraction de votre territoire actuel dans vos réflexions ; si, grâce à vos idées, nous parvenons à déplacer la contrainte hors de la DSI, je vous promets une place au paradis dans le futur directoire de la Direction Informatique ! Rendez-vous dans une semaine, même heure.

*

Quand mes trois directeurs débarquent le lundi suivant, j’ai déjà une idée très précise pour l’organisation, mais je préfère écouter plutôt que de me lancer dans un exposé magistral qui n’aurait pas les mêmes vertus thérapeutiques.
C’est Moustier, de la production, qui démarre :

– Pour moi, une organisation adaptée pour fluidifier l’innovation en respectant les contraintes de sécurité et de coût fixées par l’entreprise devra faire en sorte que 80% de la chaîne de valeur, c’est-à-dire de la chaîne qui va d’une demande au logiciel activé, soit dans le périmètre d’une seule équipe. Cela évitera l’essentiel des contrats, des négociations et autres plannings qui nous pourrissent la vie et ne servent finalement qu’à masquer la pénurie des quelques informaticiens pluri-compétents que nous avons péniblement réussi à conserver !

– C’est vrai, nous n’avons pas vraiment valorisé ces trajectoires de contremaître, ces opérationnels qui maîtrisent la technique, le métier, la communication …dis-je, pensif. Je garde néanmoins pour moi la réflexion suivante : l’absence de carrières pour opérationnels nous conduit à décourager l’intelligence en en concédant le monopole aux gestionnaires …

– Béranchon interroge : pourquoi pas, mais cela reviendrait à s’organiser autour d’applications, en répliquant dans chaque équipe des compétences que nous avons pourtant réussi à mutualiser : architecture, achats, spécialistes d’environnements techniques, grosses machines et j’en passe. N’est-on pas en train de fantasmer sur un mode organisationnel qui nous renvoie aux débuts de l’informatique, et qui a lui aussi de lourds inconvénients ?

– Lefebvre poursuit sur un ton approbateur. Tout à fait d’accord avec toi. Tout ce que l’on va réussir à faire, c’est créer des baronnies fortifiées qui, parce qu’elles auront toute l’autonomie d’une DSI pour gérer leurs quelques applications, se désintéresseront des intérêts à long terme du système d’information, qui lui, impose une certaine homogénéité des pratiques. Qui va accepter les normes de sécurité, les règles du plan de secours, ou les normes d’interfaçage ? En clair, intégration et sécurité vont être mis à mal dans notre nouveau tableau de bord !

– Conclusion : la dette technique – le passif – va augmenter, et comme vous nous l’avez brillamment démontré, Paul, les coûts suivront…. assène Béranchon.

Je reprends :

– Ne jouons pas les Cassandre inutilement. Notre nouvelle carte d’état-major doit nous permettre de visualiser et donc de piloter la dette technique. Nous pourrions très bien mettre en place un mécanisme de type pollueur/payeur qui taxe lourdement les applications ne respectant pas les enjeux long terme, comme l’interopérabilité ou la sécurité globale.

– Mmm. Vous n’allez pas me rendre la vie facile, poursuit Lefebvre. Je préfère de loin le mode actuel où je peux contrôler l’application des standards à la source, et utiliser mon droit de veto si nécessaire.

– Si votre métier était facile, je ne vous verserais pas des émoluments de ministre ! Prenons les choses à l’envers. : quelles sont les conditions nécessaires pour qu’un contrôle à posteriori, et non plus a priori, permette de garantir l’intérêt général du SI à long terme ?

– Attendez un instant…répond Lefebvre, un peu penaud.

– Moustier enchaîne : du côté de la production, je me suis forcément posé la question. Quelles sont les conditions nécessaires pour disperser une partie de mon propre département dans des unités autonomes capables de faire tourner leur propre morceau de SI ? Paul m’a dit que si je supprimais mon job j’étais promu (il se tourne vers moi et me gratifie d’un clin d’œil), donc j’ai réfléchi sans inhibition !

– Et alors ? demande un chœur

– Alors, pour me focaliser sur ce que je veux vraiment, j’ai commencé par me remémorer mes meilleurs moments. Ces moments où l’on a réussi quelque chose de grand, où les utilisateurs sont venus nous voir, et nous ont dit : bravo les gars. Et j’ai cherché la racine commune à ces situations.

– Tu veux dire que tu as trouvé des caractéristiques communes aux plus beaux projets de ton Département ?

– Pas plusieurs, une.

– Laquelle ?

– La collaboration.

– La collaboration ? Mais tout le monde collabore ici ! Et pourtant tous tes projets ne sont pas des succès … insinue Lefebvre.

– La collaboration, dans son sens noble, c’est-à-dire le travail en équipe pluridisciplinaire, dans un esprit de partage, d’apprentissage, et donc d’épanouissement de tous.

– Welcome in Bisounours-land ! persifle Lefebvre, qui commence manifestement à être agacé.

– Bien, dis-je pour l’interrompre. Et où t’as conduit cette première découverte ?

– Je me suis tout simplement dit que c’est cette énergie, ce sens que je voulais retrouver dans une nouvelle organisation. Et là, tout est devenu clair : il faut rendre autonomes des équipes du point de vue de l’exploitation de leurs systèmes ? Et bien, plutôt que de faire à leur place comme aujourd’hui, je vais désormais proposer un service de soutien qui les aide à assurer eux-mêmes l’essentiel du service.

– Quel rapport avec épanouissement ou pluridisciplinaire ? interroge Béranchon.

– Essaye d’imaginer ces équipes vraiment autonomes. Qui faut-il réunir pour construire du logiciel ?

– Des experts métiers, des analystes, des architectes, des développeurs … répond Béranchon

– Et qui faut-il ajouter pour que ces équipes non seulement construisent, mais aussi opèrent elles-mêmes leur système ?

– Et bien, des gens de chez toi : des experts techniques, des architectes systèmes et réseaux, des administrateurs de machines et de données, …

– Tout à fait. Mais s’il faut réunir tout ce monde dans chaque équipe autonome, cela va peut-être coûter cher. Je dis ça avant que Lefebvre ne me le balance à la figure, car c’est la vérité.
(rires)

Moustier poursuit au tableau :

– L’organisation actuelle mise donc sur des spécialistes, disons pour simplifier que les carrés conçoivent, les ronds développent, et les triangles exploitent.

– Dans une organisation en équipes pluridisciplinaires, les compétences principales demeurent bien entendu, mais les interactions permettent d’en développer de nouvelles. On se retrouve avec des équipes de cette forme :

Je poursuis, franchement surpris par l’intérêt de la vision de Moustier :

– Et ta conviction j’imagine est que transférer à une équipe un « petit triangle » lui permet d’assurer 80% du service, les 20% restants étant relatifs à des opérations complexes ou risquées comme …

– Moustier termine : comme des montées de version de systèmes, des audits de sécurité, de l’optimisation de performances, etc.

Béranchon semble convaincu comme moi, mais Lefebvre reste sur ses gardes :

– Toute cette autonomie sera quand même un facteur de dispersion, d’hétérogénéité ! Comment comptez-vous par exemple coordonner un projet transverse qui aurait des impacts sur plusieurs de vos équipes « produit » ?

– Très bonne question, dit Béranchon. Dans l’hypothèse où les équipes travaillent en cycles courts et sont capables de prioriser environ tous les mois de nouvelles demandes, un Directeur de Programme transverse doit pouvoir prendre la main sur plusieurs carnets de commande Produit, et ainsi faire émerger progressivement un ouvrage commun.

– Mmm, soupire un Lefebvre dubitatif.

– Je crois que nous avons fait le tour des arguments rationnels, dis-je en m’adressant à Lefebvre. Au fond, qu’est-ce qui vous ferait adhérer à notre proposition ?

– Que vous remettiez les pieds sur terre, je suppose ! Qu’au moins vous réserviez une place au contrôle ! Qu’on évite le chaos total !

– Il n’appartient qu’à vous de réserver une place au contrôle. Je précise donc ma question, quelle forme de contrôle vous ferait adhérer à notre proposition ?

Long silence, que Lefebvre finit par briser :

– Vous avez évoqué le passage du contrôle a priori au contrôle a posteriori tout à l’heure, mais j’ai du mal à me projeter dedans …

– Disons que c’est du même ordre que l’évolution d’une fonction de comptable vers celle de Commissaire aux Comptes… Comme l’a montré Moustier, plutôt que de faire à la place des gens – voire de leur interdire de faire –, créez les conditions pour que les standards émergent dans les équipes produit, puis promouvez-les et contrôlez-les a posteriori.

– Et Béranchon d’ajouter : et rien ne vous empêchera de distribuer les bons et les mauvais points selon le respect de l’intérêt général.

– Tout à fait, et ce en ouvrant vos standards à tous ! poursuit Moustier. Il doit être aussi simple de s’en servir que d’y contribuer. Les composants cœur des projets Open Source sont devenus transverses par leur qualité, leur ouverture, par l’attraction qu’ils ont exercé, pas par la force !

– On parlera plus d’exemplarité que d’autorité poursuit Béranchon. Tu devras toi aussi aider ces équipes autonomes à réaliser des systèmes complets qui s’étendent au-delà de leurs propres produits :

– Les aider à communiquer en animant des rituels réguliers, les aider à tester ensemble en leur offrant une plate-forme de tests automatisés de bout en bout, etc.

Lefebvre a changé d’attitude, son œil commence à briller et un début de sourire est apparu sur le coin de ses lèvres. Je conclue :

– Il s’agit finalement de faire massivement le pari de la confiance. Nous retombons encore sur ce principe : si nous prenons les gens pour des adultes, ils se comporteront comme des adultes.

– Et si, comme aujourd’hui, nous les prenons pour des enfants … sourit Mustier.

Alors Lefebvre, manifestement rassuré, demande :

– Très bien Messieurs. Mais si nous prônons la déspécialisation, l’acquisition de nouvelles compétences, peut-être devrions-nous aussi nous astreindre à cette discipline pour montrer l’exemple non ? Comment vais-je m’assurer de bien gérer ce nouveau territoire ouvert ?

– Et moi le développement ? ajoute Moustier

– Et moi l’exploitation ? enchaîne Béranchon

– J’ai une proposition : faisons simplement équipe comme nous le suggérons aux troupes. Réorganisons nos quatre bureaux en un grand espace ouvert où nous travaillerons ensemble. Gardons deux salles fermées pour les entretiens privés. Cela nous aidera à sortir de nos cases de directeurs spécialistes, et à incarner à la place un directoire focalisé sur l’optimum global !

– Et si nous écrivions un manifeste, lance Moustier ?

*

Pour une informatique conviviale

  • Garantir la sécurité de l’emploi pour exiger l’amélioration continue
  • Privilégier les équipes produit autonomes, responsables du fonctionnement et de l’évolution de leur système
  • Evoluer en cycles courts
  • Contrôler a posteriori plus qu’a priori : les standards émergent des meilleures pratiques
  • Valoriser les postes de contremaîtres (les opérationnels pluri-compétents), au même niveau que les gestionnaires
  • Favoriser les rencontres et l’enrichissement des compétences : animer des communautés de savoir-faire (standards) en plus des équipes produit pluridisciplinaires

-> Chapitre 8

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.