Articles Tagués ‘système d’information’

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

« 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