Le DevOps, une question d'organisation

Depuis près de 20 ans, je travaille dans le domaine de la recherche et développement logiciel, dont une grande partie en SSII. J’ai eu l’occasion d’exercer tous les métiers qui collaborent à la production d’un logiciel, ainsi que de m’intégrer à différentes organisations de toutes tailles. Je reste pourtant toujours étonné de voir comment l’identification de bonnes pratiques finit inlassablement par être détournée pour justifier notre refus de remettre en cause notre organisation.

L’approche DevOps apparait comme le nouveau buzzworld à la mode dans le monde de l’IT. À l’origine, des experts ont établi un constat bien réel et un recueil de bonnes pratiques, mais comme souvent, cela a fini par être dévoyé pour justifier des approches contreproductives. En effet, comme le développement agile avant lui, le DevOps se restreint maintenant trop fréquemment à l’utilisation d’outils.

Qui n’a pas entendu un chef de projet déclarer faire de l’agilité, et pour le démontrer, expliquer que son équipe développait en sprints successifs ? Les mêmes aujourd’hui prétendent appliquer les principes du DevOps grâce à la mise en œuvre Jenkins, Puppet ou Ansible pour automatiser leurs déploiements et chasser ainsi les opérateurs de l’équation.

Malheureusement, ces pratiques se positionnent aux antipodes des objectifs affichés par les méthodes de développement agiles et l’approche DevOps. Elles ignorent le fait que les choix d’organisation ont nettement plus d’impact sur la fluidité de la chaine de production que les outils mis en œuvre.

Utiliser les bons outils dans une mauvaise organisation c’est comme inviter AC/DC à jouer pour un diner romantique. À moins d’être un couple de fans inconditionnels, « Highway to Hell » n’est certainement pas le fond sonore idéal pour faire sa proposition.

Il est important de prendre le temps de comprendre les problèmes et de ne pas perdre de vue l’objectif, lorsque l’on souhaite trouver une solution.

Je vais commencer par rappeler les enjeux des méthodes de développement agile et du DevOps, avant d’aborder la modélisation des organisations pour montrer comment elles impactent les objectifs de ces méthodes.

Le développement agile

La mise en œuvre des méthodes de développement agile a entrainé l’aspiration du mouvement DevOps. Elles ont mis en évidence la nécessité de fluidifier les relations entre développeurs et opérateurs, mais également avec tous les autres acteurs qui participent à la production d’un logiciel.

La notion de développement agile est apparue il y a une quinzaine d’années. À l’origine, il y a un constat : en analysant les fonctionnalités utilisées par les utilisateurs d’un logiciel qui a connu plusieurs versions successives, il en ressortait que 70 % des fonctions développées pour la première version avaient disparu au bout de quelques itérations. Dans le même temps, 70 % des fonctionnalités de la version courante plébiscitées par les utilisateurs n’avaient pas été imaginées lors de la première version. Autrement dit, beaucoup de temps et d’argent était gaspillé avant d’arriver à une version adaptée aux marchés.

Les méthodes de développement agile ont introduit la conception par amélioration continue. Pour atteindre cet objectif, elles proposent de raccourcir les cycles de développement et d’outiller la mesure de l’usage utilisateur. Ainsi, transformer les mois en semaines voir en jours, permet de bénéficier plus rapidement du retour utilisateur pour adapter le logiciel aux besoins. 

L’IT a la chance, en particulier pour les services sur internet, de pouvoir procéder à des mises à jour rapides et sans frais. La conception par amélioration continue y est donc une force L’application des mêmes méthodes pour la construction d’une voiture serait beaucoup plus problématique. Cela reviendrait à attendre l’approche du premier stop pour étudier l’installation d’un système de freinage.

Mais pour s’appuyer sur l’amélioration continue, il ne suffit pas de découper le développement en courtes itérations en appliquant des méthodes comme Scrum ou Kanban. La boucle retour utilisateur constitue la notion fondatrice des méthodes de développement agile.Il s’agit d’utiliser l’analyse des usages et problèmes utilisateurs pour identifier les fonctionnalités à ajouter, supprimer ou adapter. Pour cela, il est indispensable de mettre en œuvre les moyens nécessaires dès la conception pour comprendre les usages et détecter les problèmes rencontrés par l’utilisateur.

L’autre élément primordial à ne pas perdre de vue est l’objectif du projet, en quoi il est créateur de valeur.

En effet, se focaliser sur les besoins utilisateurs et se lancer dans une course effrénée à l’amélioration continue, risque de faire perdre de vue l’objectif réel du projet.

Certes, ce serait pour le « bien » de l’utilisateur, mais pas forcément pour celui du client qui paye le développement du logiciel. 

En développement agile, à l’exception éventuellement de la première version, une roadmap à 6 mois tient de la science-fiction. La priorité consiste à mettre une première version dans les mains des utilisateurs afin de pouvoir commencer à s’appuyer sur leurs usages pour définir les développements à venir. Il faut donc traiter les améliorations et problèmes identifiés sur les versions en production avant de se projeter trop loin dans le futur.

Pour mettre en oeuvre des méthodes développement agile, il est nécessaire de

• Intégrer les remontées d’usage dès la conception
• Concevoir et développer le logiciel en courtes itérations
• S’appuyer sur les remontées utilisateurs des précédentes versions pour concevoir les suivantes.

Le DevOps

Développer en itération rapide c’est bien. Mais si derrière votre équipe d’exploitation vous contraint à deux mises en production par an, ou si vos mises à jour sont tellement hasardeuses qu’il faut 3 semaines pour stabiliser la plateforme, ce n’est pas très efficace.

Pour pouvoir réellement mettre en œuvre du développement agile, il faut donc que l’exploitation s’adapte à ces nouvelles contraintes, mais il faut également que l’équipe de développement intègre les besoins et contraintes de l’exploitation dès le début du projet.

Comment effectuer les déploiements, les mises à jour, le monitoring, le support et le troubleshouting ne peuvent plus rester des questions qui attendent l’arrivée en production pour être étudiées. Pour pouvoir effectuer des mises à jour fréquentes et sans impact, il faut que le logiciel soit pensé en ce sens.

Le DevOps est donc une conséquence du développement agile, parti d’un constat : « Dans les petites structures comme les Startups, il est beaucoup plus facile de réaliser des itérations courtes, et de les pousser jusqu’à la production que dans les grosses structures. Le dialogue et la concertation entre les différentes parties prenantes y sont également bien plus présents et efficaces ».

Le DevOps essaye donc d’identifier les bonnes pratiques des petites structures pour les appliquer dans les grosses afin de fluidifier la chaine de production d’un logiciel.

L’automatisation

Un premier élément a rapidement été identifié, aujourd’hui souvent présenté comme la clé de voute du DevOps : l’automatisation des tests et des mises en production.

Dans les petites structures, il est fréquent de constater que les tests sont majoritairement automatisés, de même que les process de déploiement en production. Cette solution permet de pousser rapidement en production une version livrée par l’équipe de développement. Mais l’automatisation n’a pas les mêmes motivations et implications dans une grosse structure que dans une petite.

Quand vous devez monter une équipe pour développer et opérer un service dans le cadre d’une Startup, vous commencez rarement par chercher un architecte, un valideur, un intégrateur ou un exploitant. Vous allez plutôt vous mettre en quête de quelques développeurs expérimentés, c’est à dire des personnes capables de porter chacune de ces casquettes, mais dont l’activité principale reste le développement.

Hors un développeur n’est généralement pas un grand fan des tâches « bêtes et répétitives ». Si vous laissez le choix à un développeur de passer 2 heures à faire des copier/coller entre fichiers ou consacrer 2 jours à l’écriture d’un convertisseur qui s’en occupera à sa place, nul doute qu’il s’attaquera au convertisseur.

Donc oui cela n’a rien d’étonnant que dans les petites structures les tests et les mises en production soient automatisés. L’automatisation permet aux développeurs de se concentrer sur leur métier premier, tout en accomplissant les tâches nécessaires pour le projet.

Toutefois, dans les grosses structures, le développeur, le valideur et l’exploitant sont souvent des personnes, voire des équipes différentes. Quand le valideur teste ses scripts de tests automatiques, recherche-t-il les bugs de son propre code ou ceux du logiciel testé ? Dans la petite structure, comme il s’agit de la même personne, il corrige les deux simultanément. Dans la grosse structure, le valideur va d’abord investiguer le problème, puis remonter un bug, qui fera à son tour l’objet d’une analyse par le développeur. De même, l’automatisation des mises en production par les équipes de développement risque d’affaiblir le niveau de connaissance de l’équipe d’exploitation sur le produit et donc entre autres de fragiliser son autonomie pour la résolution d’incident. 

Il ne s’agit pas ici de prétendre que l’automatisation soit une mauvaise chose, mais de montrer que la façon dont elle est mise en œuvre peut entrainer des effets pervers. S’il est nécessaire d’automatiser les tâches « bêtes et répétitives », nos organisations doivent être adaptées pour confier la responsabilité de ces actions aux bons acteurs.

Une question d’organisation

Se focaliser sur les méthodes et outils mis en œuvre dissimule l’éléphant qui se tient au milieu de la pièce. La plus grosse différence qui existe entre les petites structures et les grosses est la taille de l’organisation.

• Les petites structures se composent généralement de peu de personne, multi casquettes et qui travaillent en équipe.
• Dans les grosses structures, il n’est pas rare de trouver beaucoup d’intervenants qui exercent un seul rôle, cloisonnés dans des entités métiers distinctes.

Dans les deux cas, nous retrouvons globalement les mêmes rôles. Si dans les petites structures, toute l’équipe cherche à atteindre l’objectif commun, il n’est pas rare que dans les grosses structures, les différents intervenants, dispersés dans des silos métiers disjoints, se voient affecter des objectifs contradictoires. 

Quand les développeurs sont objectivés sur leur capacité à livrer de nouvelles versions très fréquemment, les opérateurs sont eux objectivés sur la stabilité du produit. Pourtant le changement risque toujours de faire apparaitre des dysfonctionnements.

Mais quel est l’influence de l’organisation sur l’aptitude du projet à réagir, s’adapter et à mettre en place de « l’agilité » de bout en bout de la chaine de production ?

Les organisations

Il y a 20 ans, j’ai commencé ma carrière dans une petite startup qui s’efforçait de promouvoir une méthode d’analyse « révolutionnaire » des systèmes sociaux techniques : « l’analyse décisionnelle ». Pour faire simple, c’était un outil de modélisation des organisations humaines et des systèmes informatiques qu’elles utilisent. La startup a fait faillite pour différentes raisons : il est très difficile de vendre une méthode qui n’a pas fait ses preuves, il est d’ailleurs très difficile de vendre une méthode tout court.

Quoi qu’il en soit, en m’inspirant de cette méthode et de ce que j’ai appris depuis, je pense pouvoir montrer comment le choix de l’organisation peut influencer la fluidité et l’efficacité de la chaine de production de logiciel.

Les savoir-faire

Avant de parler d’organisation, il est intéressant de se pencher sur les savoir-faire. Les savoir-faire sont les processus mis en œuvre pour atteindre l’objectif fixé et réaliser ce qu’il y a à faire. À la question « qui fait quoi ? », l’organisation est le « qui », les savoir-faire sont le « quoi ».

La méthode proposait de modéliser un savoir-faire sous forme d’un composant « boite noire » à quatre pattes, deux entrées et deux sorties lui permettant de communiquer avec les autres savoir-faire.

• L’entrée haute correspond à l’assignation de la mission.
• La sortie haute permet de remonter les résultats finaux ou intermédiaires
• La sortie basse représente la délégation
• L’entrée basse permet de récupérer les résultats des délégations.

La méthode traitait également de la modélisation du fonctionnement de la boite noire, mais cela à peu d’intérêt pour la question qui nous occupe.

Ces savoir-faire peuvent donc s’assembler pour composer un savoir-faire plus complexe en branchant l’entrée haute de l’un sur la sortie basse de l’autre et la sortie haute sur l’entrée basse. Le savoir-faire du haut justifie le « pourquoi » de la mise en œuvre du savoir-faire du bas. Le savoir-faire du haut délègue la poursuite d’un objectif à celui du dessous.

Il est ainsi possible de combiner différents savoir-faire en tendant à réaliser une structure hiérarchisée par la délégation. Le savoir-faire supérieur porte la finalité de ce processus, les savoir-faire intermédiaires déclinent cette stratégie en sous-objectif jusqu’à atteindre les savoir-faire les plus bas chargés de la réalisation.

Le résultat est plaisant pour l’esprit, il est ainsi possible de modéliser ce qu’il y a à faire sous la forme d’une structure hiérarchisée par la délégation. Cela permet de montrer toute l’importance de la stratégie et du pilotage par rapport à la réalisation. Mais ce n’est que la modélisation du « quoi ». Il reste à définir le « qui », c’est-à-dire identifier les pilotes qui mettront en œuvre ces savoir-faire.

L’idée porter par la méthode, finalement plutôt partagée par le management, est que si le « quoi » est correctement modélisé, le « qui » n’a que peu d’impact.

 La méthode restait peu détaillée sur ce point et ce qui constituait l’une de ses principales faiblesses.

L’organisation

Définir une organisation hiérarchisée par la notion de délégation ou de responsabilité, consiste à affecter un pilote ou un acteur à un ou plusieurs savoir-faire.

Mais est-ce qu’une jolie structure hiérarchisée constitue la solution la plus adaptée pour conduire un projet ? 

Contrairement à l’idée reçue, déléguer un savoir-faire à un pilote tiers ou le faire soi-même change beaucoup de choses, après tout on n’est jamais mieux servi que par soi-même.

Si la délégation a des avantages évidents, en particulier pour ce qui concerne la gestion de la charge de travail, elle a également un cout. Bien comprendre les implications d’une délégation est indispensable pour mettre en place une organisation constructive et efficace.

Les 7 points de vigilance

1/7 Les boites noires

L’analyse décisionnelle considère les savoir-faire comme des boites noires qui ne partagent pas leurs états internes entre eux. Le problème c’est que l’être humain n’est pas un pilote parfait. 

L’être humain ne cloisonne pas sa pensée, comme peu l’être la mémoire entre deux processus sur un ordinateur. Il n’a pas de notion de boite noire. Par exemple, si vous demandez à un acteur de se charger de deux savoir-faire dont l’un délègue à l’autre, en réalité, il va mettre en œuvre un savoir-faire diffèrent de ceux précédemment modélisés. Il va les fusionner pour n’en faire plus qu’un, mais il fera également disparaitre la communication entre ces activités.

Cela va avoir pour conséquence de supprimer des éléments qui permettent la traçabilité des processus, mais le plus gros problème pourrait être la perte d’objectivité des analyses et décisions. Si un acteur se retrouve à arbitrer l’un de ses savoir-faire et celui d’un autre acteur, ses décisions risquent d’être biaisées par sa connaissance de son savoir-faire subalterne.

2/7 Les prismes de perception

Là où l’impact est le plus évident, c’est sur la communication. Quand deux êtres humains communiquent, ils doivent traduire leurs idées en phrases qui seront elles-mêmes retraduites en idées. Chacune de ces traductions est biaisée par ce qu’on appelle le prisme de perception. En fonction de la culture, de son état d’esprit et de la personne avec qui nous communiquons, les mêmes idées ne seront pas énoncées avec les mêmes mots, et les mêmes mots ne donneront pas forcément les mêmes idées.

Ainsi plus les chaines de décision sont longues, plus on augmente le risque de voir les informations se déformer. C’est quelque chose d’assez connu dans les grandes entreprises, quand la base remonte des dashboards tout rouges, ceci finissent par devenir tout vert quelques niveaux hiérarchiques plus haut, après tout c’est naturel, les pommes mures tombent au sol.

3/7 Le timing

Quand un être humain communique avec lui même, le transfert d’information est précis, mais également instantané. Lorsque deux êtres humains dialoguent, l’information risque non seulement d’être déformée, mais le transfert va prendre du temps.

« En tant qu’expert technique, lorsque je dois remonter une information à ma hiérarchie, je dois agrémenter cette information d’explications afin de permettre à mon responsable d’en acquérir une compréhension suffisante pour prendre les décisions et actions adaptées. »

Plus la chaine de décision implique un grand nombre d’acteurs, plus le délai entre la remontée d’une alerte et la mise en œuvre de l’action corrective va s’allonger.

4/7 La chaine d’incompétence

Les experts techniques possèdent par définition des connaissances, expériences et compétences que ne maitrisent pas les autres acteurs du projet. Bien souvent, les acteurs qui disposent du plus d’expertise sur le logiciel produit se trouvent en bas de l’organigramme, au contraire plus les acteurs grimpent dans la hiérarchie, plus ils s’éloignent de la technique.

Lorsqu’un opérateur identifie un bug qui doit être corrigé par un développeur, alors que : 

• S’ils peuvent dialoguer directement ensemble, ils vont rapidement s’accorder sur l’analyse et proposer des mesures correctives.
• S’ils doivent communiquer au travers de leur hiérarchie respective, ils devront échanger par l’intermédiaire d’une chaine de « bouche-à-oreille » ce qui va complexifier et retarder l’analyse du problème et l’émergence d’une solution.

En d’autres termes, plus les chaines de décision comportent d’intermédiaires, plus vous courrez le risque que les décisions soient prises sur la base d’informations erronées et obsolètes, par des gens qui ne disposent pas de l’expertise requise.

5/7 La responsabilité

Lorsque l’on construit une organisation hiérarchisée par la délégation il est important de comprendre la notion de délégation et en particulier la différence qu’il y a entre déléguer et donner un ordre. Quand vous êtes un élément d’une chaine de commandement, vous devez suivre les ordres, pas les comprendre. La responsabilité de vos actions incombe à votre supérieur (même si l’histoire nous montre que ce n’est pas une défense humainement acceptable).

Lorsque vous faites partie d’une chaine de délégation, il vous est demandé d’atteindre un objectif, l’acceptation de cet objectif et les moyens à mettre en œuvre sont de votre responsabilité.

Lorsque vous déléguez, vous transférez une partie de votre responsabilité aux acteurs à qui vous avez délégué. Plus vous descendez dans l’organigramme, moins il y a de responsabilités à partager. Quand la chaine est trop longue, les derniers acteurs n’ont donc plus de responsabilité du tout.

Le problème est qu’avec la responsabilité vient la motivation. Pourquoi chercher à faire mieux quand tout ce que l’on attend de vous c’est de suivre les ordres ? Un développeur n’est pas un soldat qui choisit de se sacrifier pour la patrie reconnaissante.

6/7 Petit faiseu et grand diseu

Depuis 20 ans, il nous est répété tel un dogme religieux que la responsabilité se paye. Plus vous avez de responsabilités et donc plus vous êtes haut placé dans l’organigramme, plus vous méritez un salaire élevé. Et comme notre société de consommation nous exhorte à dépenser toujours plus, tout le monde cherche à obtenir une promotion et s’éloigner des métiers du faire, pour aller vers ceux du faire-faire. Mais comme les carrières sont longues, le risque est de rapidement se retrouver avec plus de barreurs que de rameurs.

Comme il n’est pas valorisant d’être inutile, ces armées de barreurs ont tendance à s’inventer de nouveaux rôles pour justifier leur présence dans l’organigramme. C’est pourquoi, malgré les bonnes pratiques enseignées par les méthodes de développement agile, nous voyons se multiplier dans les grosses structures les comités de pilotage, les outils de reporting, les productions de roadmap et de réunion de suivie. Au final, la part gestion devient plus importante que la part production.

Le problème c’est que pour gagner de l’argent il est nécessaire de produire, et pour cela il faut des gens qui font. Les petites structures ne peuvent se payer le luxe d’une structure hiérarchique démesurée et sont obligées de valoriser les acteurs responsables de la production sous peine de disparaitre.

7/7 Les agora

L’un des problèmes des organisations hiérarchisées est qu’il faut obligatoirement un chef pour piloter tous les autres. Ce principe est culturellement bien établi que ce soit dans nos entreprises ou nos gouvernements. Pourtant en observant les petites structures, il est assez fréquent de trouver à leur tête un groupe de personnes, en général de métier diffèrent (technique, marketing, financier, commerce…), travaillant de concert au pilotage de l’entreprise.

Comme il s’agit de petite structure, ils sont généralement acteurs de la chaine de production.

Si la méthode d’analyse décisionnelle permettait d’affecter plusieurs savoir-faire à un pilote, elle n’envisageait pas de répartir un savoir-faire sur un groupe de pilotes. Pourtant, c’est bien souvent ce que nous pouvons observer et cela va de pair avec la responsabilisation des acteurs.

Lorsque l’objectif commun et les responsabilités de chacun sont correctement définis, les différents acteurs du projet disposent de la maturité et des éléments pour prendre ensemble les décisions stratégiques.

Retour vers le DevOps

L’objectif du DevOps est de définir les moyens pour que les chaines de production de logiciel soient le plus fluide et efficace possible. Qu’elles soient capables de s’adapter rapidement aux objectifs bizness. Le DevOps fait des petites structures l’inspiration pour atteindre cet objectif.

Ce qui fait la force des petites structures, c’est la mise en œuvre de petites organisations pluridisciplinaires qui œuvre en équipe, c’est à dire fortement impliquées dans la réalisation d’un objectif commun.

Pour qu’une équipe soit efficace, elle doit être fédérée autour d’un objectif commun, mais également :

• Responsabiliser ses acteurs
• Disposer des chaines de décision courte pour favoriser le dialogue
• Chercher à réduire l’altération de l’information par l’humain 
• Laisser la possibilité aux acteurs techniques d’échanger sans intermédiaire
• Valoriser le faire et non le faire-faire

L’automatisation des déploiements.

Tout le monde parle d’automatisation quand est abordé le sujet DevOps. Il est en effet bien plus simple de demander aux développeurs/intégrateurs d’automatiser les déploiements avec des outils comme Puppet, Ansible ou Docker plutôt que de remettre en cause nos organisations. D’autant que lorsque l’organisation est performante, l’automatisation est constructive. Elle permet de sécuriser les opérations en réduisant la part de l’erreur humaine, mais aussi de s’assurer que l’action est réalisée par les experts du sujet.

L’organisation est bonne quand les responsabilités de chacun sont clairement définies et que l’objectif commun est précisément établi.

Pour les projets qui n’ont pas réellement besoin d’une équipe d’exploitation, autant ne pas s’encombrer d’une équipe d’exploitation et laisser les développeurs mettre en place les processus de gestion de la production.

Par contre, sur un projet qui, pour différentes raisons, nécessite une équipe d’exploitants, il est important que cette équipe possède une excellente connaissance du produit. Il est alors préférable de lui confier la responsabilité de l’automatisation des déploiements, et ce, dès les phases de développement pour faciliter l’acquisition de cette expertise.

Le problème n’est donc pas de savoir s’il faut ou non automatiser, mais de déterminer qui doit en prendre la responsabilité. Faire de l’automatisation dans le cadre du DevOps revient à faire disparaitre l’intégrateur et à confier ses responsabilités aux développeurs et/ou aux opérateurs.

La mise en place de tests automatiques.

Tout comme pour les tâches d’exploitation, bien positionner la responsabilité de la validation va être un élément déterminant pour la fluidité des processus. 

Pour être efficace dans l’écriture des tests de qualification, il faut une bonne connaissance de son fonctionnement attendu, mais également de son architecture interne. 

Les développeurs disposent de cette expertise. Une autre équipe qui peut (si elle existe) avoir besoin de cette connaissance, c’est l’équipe de support client chargée des analyses et diagnostics des problèmes remontés sur la production.

Si l’équipe de développement porte la responsabilité de l’analyse et du diagnostic, il est peut-être préférable de la laisser endosser la responsabilité de la validation. Elle sera ainsi responsable du choix des processus et moyens qu’elle jugera les mieux adaptés pour atteindre l’objectif.

Si par contre vous avez besoin d’une équipe dédiée au support client, il serait surement intéressant de lui confier également la responsabilité de la validation. Cela permettrait de s’assurer de sa montée en compétence et lui donnerait la possibilité d’anticiper les problèmes utilisateurs et d’adapter les fiches de tests aux incidents rencontrés en production.

En conclusion

Indépendamment des buzzworlds, pour obtenir des équipes efficaces et performantes, il est nécessaire de revoir nos organisations et la valorisation du travail. Il faut s’efforcer de garder des chaines de décision courtes et de maintenir autant de responsabilités que possible sur les acteurs techniques. Pour cela, il est indispensable de prendre le temps de bien définir les responsabilités de chacun. Les acteurs du développement logiciels sont des ingénieurs, des cadres, qui ont les capacités de gérer des responsabilités. 

Il est primordial d’identifier où se situe la création de valeurs et de rémunérer les acteurs en conséquence. Il est préférable de les encourager à se maintenir sur les métiers du faire que de les pousser vers ceux du faire-faire.

Il faut favoriser l’élargissement des champs de compétence plutôt que d’encourager les spécialisations.

Mais le plus important, l’élément dont découlera tout le reste, il faut objectiver les projets sur leur création de valeurs (directe ou non) et partager cet objectif avec tous les acteurs du projet.