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

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

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

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

– Disons trois mois maximum.

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

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

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

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

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

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

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

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

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

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

– Parfait. Comment allez-vous procéder ?

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

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

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

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

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

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

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

– Je vois que la plaie est encore vive…

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

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

*

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

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

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

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

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

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

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

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

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

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

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

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

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

*

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

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

Les visages restent interloqués, je poursuis :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Lesquelles ? dis-je en l’interrompant.

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

Pendant ce temps, Kasperski note au tableau :

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

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

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

Kasperski l’interrompt :

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

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

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

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

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

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

Jean-Pierre enchaine :

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

Je conclus :

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

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

*

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

Après son départ, Kasperski commente :

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

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

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

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

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

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

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

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

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

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

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

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

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

Jérôme intervient alors :

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

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

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

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

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

– Ah !

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

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

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

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

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

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

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

*

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

Bernard réfléchit :

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

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

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

– Comment peut-on s’en sortir alors ?

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

– Et la seconde option ?

– Continuer à déroger aux règles.

– Comment cela ?

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

– J’appelle Paul ! conclut Jean-Pierre.

*

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

Bernard me tire de mes pensées :

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

– Comment ?

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

– Oui, allez-y.

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

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

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

*

Dring !

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

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

– Oui, c’est exact.

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

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

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

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

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

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

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

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

-> Chapitre 5