comment industrialiser lesloicmieral.fr/wp-content/uploads/2017/09/loïc... · ainsi autour des...

SCIENCES U LYON

Comment industrialiser les systèmes d’information par

le mouvement DevOps ? Mémoire – Expert en Ingénierie Informatique

Loïc MIERAL

2013-2015

Re sume (FR)

D’après un sondage réalisé par VersionOne, acteur reconnu de la mise en œuvre des nouvelles

méthodes informatiques, les équipes IT modernes sont en moyenne 60% plus productives et 60% plus

rapides pour répondre aux changements que les équipes traditionnelles.

DevOps est un mouvement fondé en 2009 par Patrick Debois et Andrew Clay Shafer destiné à

améliorer les méthodes Agiles en incluant une composante opérationnelle dans la gestion des

projets IT. La pratique DevOps se veut être une idéologie rationnelle répondant à l’un des problèmes

majeurs constaté dans les directions des systèmes d’informations modernes : la structure des

équipes actuelle démontre un manque de collaboration interservices pénalisant la réussite des

conduites de projet IT. Ce manque de coopération éloigne les équipes de l’objectif collectif commun

à toutes les directions des systèmes d’information, à savoir la production logicielle continue et la

stabilisation des infrastructures IT. Le résultat de cette lacune entraine une véritable étanchéité des

équipes qui divise les différents départements informatiques, laissant place à des situations

conflictuelles impactant la performance et la qualité du système d’information. Ce constat n’est

aujourd’hui plus tolérable dans un environnement dynamique devenu hautement concurrentiel.

DevOps se veut donc être une culture prônant le rassemblement de tous les acteurs et plus

particulièrement des développeurs, les « Dev », et des opérationnels, les « Ops ». Outre la simple

amélioration des processus de collaboration, DevOps est un mouvement communautaire évolutif qui

cherche à instaurer une nouvelle façon de travailler au travers de ses nombreuses valeurs et de ses

principes. DevOps agit ainsi directement sur l’environnement IT, la communication interservices, les

comportements internes, la standardisation des processus, la sélection des outils et des technicités à

mettre en œuvre.

Toutefois, l’intégration de la culture DevOps dans des organisations IT toujours plus complexes

nécessite une parfaite maitrise du fonctionnement des directions des systèmes d’information

actuelles. Un changement substantiel sur les processus de collaboration et sur la conduite de projet

génère inévitablement un stresse important pour les collaborateurs. Ce stresse doit par conséquent

être maitrisé par une conduite du changement judicieuse et menée rigoureusement au travers d’une

politique de management adaptée.

Par ailleurs, DevOps se veut être avant tout une culture, une idéologie non loin de l’utopisme. Elle ne

donc être intégrée à une organisation interne sans méthodes complémentaires orientées sur des

aspects plus concrets et spécifiques qui sont adaptés à l’activité de l’organisation. DevOps s’articule

ainsi autour des nouvelles pratiques actuelles telles que Agile et Scrum. La combinaison de ces

approches multiples permet d’obtenir des synergies dans la réalisation des projets IT.

De plus, dans une optique d’amélioration continue des structures informatiques, DevOps permet

d’automatiser les processus de développement, de mise en production, de tests, de supervision, de

conduite de projets et d’analyse de la performance autrefois impossible à atteindre. Il devient alors

possible de procéder à une véritable industrialisation du système d’information à l’échelle globale de

l’organisation. Il en résulte un accroissement considérable de la productivité pour les services de

recherche et développement, une amélioration de la qualité globale du SI et une réactivité

incomparable pour la détection et la résolution des incidents. Enfin, les acteurs IT bénéficient de ces

améliorations par le profit d’un contexte de travail propice à l’épanouissement et à la réalisation de

soi.

Abstract

According to a survey conducted by VersionOne, one of the major actor of new informatics process

implementation, modern IT team are 60% more productive and faster to answer the change of

traditional team.

DevOps is a new movement founded on 2009 by Patrick Debois and Andrew Clay Shafer designed to

improve Agiles methods included operational component into IT projects management. The aim of

DevOps is a rational ideology in order to answer one of the major issue noticed in the management

of modern information system : actual team structure shows a lack of cross service team building

penalizing the realization of IT projects conduction. This lack of team building is drifting apart the

different crews of the common goal of the management of the information systems. Their mains

missions are the production continue of software and the stabilisation of IT infrastructure. The result

of that lack is a complete sealing of the team and divided the different informatics department which

leaving place to conflictual situation directly impacting the performance and the quality of the

information system. In nowadays, this observation is no longer acceptable in a highly dynamic and

competitive environment.

DevOps wants to be a culture advocating the gathering of all actors and specifically the developers,

the “Dev” and operations, the “Ops”. Despite improving the process of collaborating different team,

DevOps is an evolving community movement which looking for establish a new way of working. This

way is based on many values and principles. DevOps act differently on IT environment, cross service

communication, internal behaviour, process standardisation, tools selection and technics to

implement.

However, the integration of the DevOps culture in IT organisation is more and more complex which

need a perfect control of the operation in the management of information systems. A substantial

change on collaboration process and on how to conduct project generate a lot of stress for the team

members. This stress must be control by a wise conduct of the change. This conduct of change pass

by an adapt policy of management.

Besides that, DevOps want to be a culture, an ideology not far from a utopia. It cannot be integrate

to an internal organisation without complementary method oriented on concretes and specifics

aspects which are adapted to the activity of the organisation. DevOps articulate is method around

new practice such as Agile or Scrum. The combination of those multiple approach allow new synergy

in IT project realization.

Moreover, in a view of a continued improvement of informatics structure, DevOps permit to

automatize process of development, put into production, tests, supervision, conducting projects and

analysing the performance which was unable to reach before. With those kind of improvement, it

become possible de create a real industrialization of the information technology. The main result is

an increase of the service productivity for R&D department. It also permit an improvement of the

global productivity of the IS and an incomparable reactivity for detection and resolution of issues.

Finally, IT actors benefits of these improvement by a working context suitable to blooming and self-

realization.

Remerciements

Pour Sciences U Lyon …

Mes premiers mots d’adressent à Jean MICHEL, mon tuteur de mémoire, pour ses précieux conseils,

son aide et son enseignement depuis la licence CSIA jusqu’aux derniers instants du master EII.

Une profonde gratitude envers Monsieur BOUICHE, directeur pédagogique, pour son assistance et

son encadrement durant les trois ans d’études passées à Sciences U Lyon.

Merci à Aude Lacour, conseillère pédagogique, pour m’avoir permis d’intégrer Sciences U Lyon et

pour son suivit et son implication tout au long de la formation.

Un grand merci à toute l’équipe d’enseignement de Sciences U pour l’enseignement inculqué et

l’ouverture d’esprit que j’ai acquise durant ces 3 ans grâce à eux.

Pour mes proches …

A mes parents qui ont supporté mes humeurs dans des moments délicats et aidé sur tous points de

vue.

A mes grands-parents pour leur soutient infaillible et leurs multiples attentions depuis ma tendre

enfance.

Pour mes proches collaborateurs …

A Vincent GAYTON, coordinateur systèmes, mon supérieur direct et tuteur d’entreprise, pour sa

patience, sa pédagogie, sa sympathie et son soutien inestimable au quotidien.

A Olivier BARBIER-VIEY, chef de projets, et Dominique ARMIGNIES, responsable des systèmes

d’information, pour leur formation et leurs nombreux conseils depuis mon intégration dans le groupe

Fiducial en 2013.

A toute mon équipe : Julien, Joël, Stéphane T, Nicolas, Charles Edouard, Fabrice, Rémi, Stéphane P et

Stéphane D pour leur bonne humeur de tous les jours.

Et à tous mes camarades de promotion Sciences U Lyon.

Sommaire Introduction ............................................................................................................................................................ 1

1. Etat de l’art du DevOps ....................................................................................................................................... 3

1.1. DevOps, un mouvement, une culture .......................................................................................................... 3

1.1.1. Objectif du mouvement ....................................................................................................................... 3

1.1.2. La culture .............................................................................................................................................. 4

1.1.3. Les apports de DevOps ......................................................................................................................... 7

1.1.4. Les DevOps Days ................................................................................................................................... 9

1.2. Une approche pragmatique ......................................................................................................................... 9

1.2.1. Introspection sur l’origine du mouvement ........................................................................................... 9

1.2.2. Une pratique collective ...................................................................................................................... 12

1.3. Un complément des méthodes Agiles ....................................................................................................... 13

1.3.1. Définition des méthodes Agiles .......................................................................................................... 13

1.3.2. Les méthodes dites Agiles .................................................................................................................. 16

1.3.3. Les limites des méthodes Agiles ......................................................................................................... 20

1.4. Un complément au « continuous delivery » .............................................................................................. 21

1.4.1. Définition du « continuous delivery » ................................................................................................ 21

1.4.2. Cohésion de DevOps avec le « continuous delivery » ........................................................................ 23

1.5. Les outils DevOps ....................................................................................................................................... 24

1.5.1. Gestionnaires de configurations serveurs .......................................................................................... 24

1.5.2. Outils d’intégration continue ............................................................................................................. 25

1.5.3. Outils de supervision .......................................................................................................................... 26

1.5.4. Gestionnaires de versions .................................................................................................................. 26

1.5.5. Outils d’analyse de la performance .................................................................................................... 27

1.5.6. Outils de gestion des logs ................................................................................................................... 28

1.5.7. Solutions propriétaires DevOps .......................................................................................................... 28

1.6. Un mouvement naissant mais reconnu ..................................................................................................... 29

1.6.1. Au cœur de l’actualité ........................................................................................................................ 29

1.6.2. Exemple de pratique DevOps - Netflix ............................................................................................... 30

1.6.3. Exemple de pratique DevOps - OVH ................................................................................................... 34

2. Les rouages des DSI et leurs complexités .......................................................................................................... 36

2.1. Qualification et structure d’une DSI .......................................................................................................... 36

2.1.1. Le rôle d’une DSI ................................................................................................................................. 36

2.1.2. La structure organisationnelle ............................................................................................................ 36

2.1.3. Evaluer la performance de l’équipe et de la DSI ................................................................................ 39

2.1.4. L’évolution de la DSI ........................................................................................................................... 40

2.2. Les enjeux de performance du SI ............................................................................................................... 41

2.2.1. Les enjeux économiques .................................................................................................................... 41

2.2.2. Une exigence qualitative .................................................................................................................... 42

2.3. Analyse des relations sociales .................................................................................................................... 43

2.3.1. La position de l’homme dans la structure .......................................................................................... 43

2.3.2. Les canaux de communication ........................................................................................................... 44

2.3.3. Les différences de perception entre les équipes dans les DSI ............................................................ 46

2.3.4. Les pressions managériales ................................................................................................................ 48

2.4. Théories et concepts de management appliqués aux organisations IT ..................................................... 49

2.4.1. La hiérarchie des besoins selon Maslow ............................................................................................ 49

2.4.2. Les X et les Y ....................................................................................................................................... 51

2.4.3. Les sphères de contrôle et d’influence ............................................................................................... 54

2.4.4. La gestion du comportement des collaborateurs .............................................................................. 55

3. L’industrialisation du SI par DevOps ................................................................................................................. 59

3.1. Développer la culture DevOps ................................................................................................................... 59

3.1.1. Construire la confiance ....................................................................................................................... 59

3.1.2. Générer de la transparence ................................................................................................................ 61

3.1.3. Œuvrer pour la coopération Dev - Ops ............................................................................................... 62

3.1.4. Empêcher les blâmes inconvenants ................................................................................................... 65

3.1.5. Encourager l’innovation ..................................................................................................................... 66

3.2. Conduire le changement ............................................................................................................................ 68

3.2.1. Appréhender le changement en douceur .......................................................................................... 68

3.2.2. Le processus de transition personnelle .............................................................................................. 69

3.2.3. Adopter un style de management adapté.......................................................................................... 71

3.3. Choisir ses outils ........................................................................................................................................ 72

3.3.1. Les critères de sélection ..................................................................................................................... 72

3.3.2. Un contexte favorable à l’open source .............................................................................................. 73

3.3.3. Un schéma d’industrialisation moderne ............................................................................................ 74

3.4. La route vers l’industrialisation du SI par la synergie des procédés .......................................................... 76

3.4.1. Compatibilité des méthodes Agiles avec DevOps .............................................................................. 76

3.4.2. Combinaison des méthodes Agiles, Scrum et de DevOps .................................................................. 76

3.4.3. Combinaison d’Agile, Scrum, DevOps et « Continuous Delivery » ..................................................... 77

Conclusion ............................................................................................................................................................. 81

Table des illustrations

FIGURE 1 : REPRESENTATION DES ACTEURS DEVOPS ........................................................................................................... 3

FIGURE 2 : LES ACTEURS D’UN PROJET IT COMPLEXE ........................................................................................................... 4

FIGURE 3 : LES VALEURS DE LA CULTURE DEVOPS ............................................................................................................... 5

FIGURE 4 : REPRESENTATION GRAPHIQUE DE LA CULTURE DEVOPS ........................................................................................ 7

FIGURE 5 : ENQUETE DE VANSON BOURNE, 2013 - LES BENEFICES DE DEVOPS OBSERVES PAR 1300 DECIDEURS IT DE 21 PAYS ........ 8

FIGURE 6 : PLANNING DES DEVOPS DAYS PAR WWW.DEVOPSDAYS.ORG ................................................................................. 9

FIGURE 7 : PROCESSUS DE DEVELOPPEMENTS ACME LOGICIELS - VERSION 1.0 ...................................................................... 10



FIGURE 10 : EXEMPLE D'APPLICATION DE LA METHODOLOGIE AGILE EN MODE SCRUM PAR L'ENTREPRISE ESKER ........................... 14

FIGURE 12 : PROCESSUS DE « CONTINUOUS DEPLOYMENT » ............................................................................................. 22

FIGURE 13 : COMPOSANTES DU « CONTINUOUS DELIVERY » .............................................................................................. 22

FIGURE 14 : REPRESENTATION DE L'ASSOCIATION DU « CONTINUOUS DELIVERY » ET DE DEVOPS.............................................. 24

FIGURE 15 : EVOLUTION DES RECHERCHES CONTENANT LE MOT "DEVOPS" SUR GOOGLE ......................................................... 29

FIGURE 16 : CONCEPT DE LA SIMIAN ARMY PRESENTEE PAR NETFLIX .................................................................................... 32

FIGURE 17 : REPRESENTATION D'UNE ORGANISATION STRUCTURELLE D'UNE DSI DE TAILLE PETITE OU MOYENNE .......................... 37

FIGURE 18 : REPRESENTATION D'UNE ORGANISATION COMPLEXE DE DSI D'UNE DIMENSION HUMAINE IMPORTANTE ..................... 38

FIGURE 19 : REPRESENTATION GRAPHIQUE DES DIFFERENTS STADES DE MATURITE D'UNE CELLULE DE TRAVAIL.............................. 40

FIGURE 20 : LA POSITION DE L'HOMME DANS UNE STRUCTURE DE GRANDE TAILLE ................................................................... 44

FIGURE 21 : COMPARATIF DES CANAUX DE COMMUNICATION INTERNES ............................................................................... 46

FIGURE 22 : LES OBJECTIFS OPPOSABLES DES DEV ET DES OPS ............................................................................................. 47

FIGURE 23 : LA CHAINE DE TRANSMISSION DE LA PRESSION ENTRE LES ACTEURS D'UN PROJET IT ................................................ 49

FIGURE 24 : PYRAMIDE DES BESOINS SELON ABRAHAM MASLOW ........................................................................................ 50

FIGURE 25 : REPRESENTATION DYNAMIQUE DE LA HIERARCHIE DES BESOINS SELON MASLOW ................................................... 51

FIGURE 26 : ILLUSTRATION DU CERCLE VICIEUX DE LA THEORIE DES X .................................................................................... 52

FIGURE 27 : ILLUSTRATION DU CERCLE VERTUEUX DE LA THEORIE DES Y ................................................................................ 53

FIGURE 28 : SPHERES DE CONTROLE, D'INFLUENCE ET D'INTERETS ........................................................................................ 54

FIGURE 29 : LES ZONES DE MAITRISE .............................................................................................................................. 56

FIGURE 30 : MATRICE DES NEUF ETATS EMOTIONNELS ...................................................................................................... 57

FIGURE 31 : SCHEMA DE CONFIANCE ENTRE LES PRINCIPAUX ACTEURS IT .............................................................................. 59

FIGURE 32 : LES COMPOSANTES DE LA COMPETENCE ......................................................................................................... 62

FIGURE 33 : MATRICE DES AVANTAGES ET INCONVENIENTS DE MODIFICATION DES INTENTIONS ................................................. 64

FIGURE 34 : COMPARAISON VS BLAME ........................................................................................................................... 65

FIGURE 35 : LE CERCLE VICIEUX DE L'ECHEC ..................................................................................................................... 65

FIGURE 36 : LE PROCESSUS DE TRANSITION SELON JOHN FISHER, 2012 ................................................................................ 69

FIGURE 37 : LISTE DES OUTILS DEVOPS .......................................................................................................................... 74

FIGURE 38 : PROPOSITION D'UNE INFRASTRUCTURE EQUIPEE D'OUTIL DEVOPS ...................................................................... 75

FIGURE 39 : COMBINAISON AGILE + DEVOPS + SCRUM + CD ............................................................................................ 77

FIGURE 40 : AMELIORATION DE LA PRODUCTIVITE ............................................................................................................ 78

FIGURE 41 : MATRICE DE COMPATIBILITE ET SYNERGIE DES PROCEDES .................................................................................. 80

Comment industrialiser les systèmes d’information par le mouvement DevOps ?

[1]

Introduction

« Plutôt qu’un marché, DevOps est plus une philosophie, un changement culturel qui associe les deux

mondes du développement et des opérations » déclare Laurie Wurster, directrice de recherche chez

Gartner.

Cinq ans après la création du mouvement en 2009, l'émergence des nouveaux outils DevOps tels que

Chef, Puppet, Docker, Jenkins ou encore Ansible a dynamisé un marché en forte croissance estimé

aujourd'hui à plus de 2.3 milliards de dollars pour l'année 2015. Soit une croissance de près de 20%.

L'adoption de cette nouvelle idéologie par les géants du web 2.0 que sont Google, Microsoft,

Facebook, Amazon, Netflix ou encore Linkedin démontre l'importance des enjeux liés aux nouvelles

pratiques informatiques. Ces grands acteurs ouvrent la voie vers de nouveaux modèles de travail

considérés comme exemplaires tant ces sociétés performent dans leur domaine. Ces leaders les plus

cotés du NASDAQ100 tirent profit de leur avance technologique pour se créer des avantages

concurrentiels. C'est l'une des raisons pour laquelle Gartner estime que 25% des plus grands groupes

mondiaux s'orientent massivement vers DevOps.

Par ailleurs les entreprises prennent conscience de leurs lacunes organisationnelles concernant un

manque de collaboration inter-équipes et un ralentissement de l'innovation. Ces faiblesses se

révèlent être encore plus pénalisantes dans un contexte concurrentiel qui s'intensifie de jour en jour

avec l'apparition et la multiplication des start-up informatiques. Les sociétés en viennent alors à

s'interroger sur les techniques d'industrialisation du SI. Le DevOps et le Continuous Delivery en sont

la clef de voûte. Il convient alors de s'interroger sur comment orchestrer l'industrialisation des SI par

DevOps.

La pertinence de cette problématique se confirme par la forte croissance que connait DevOps qui

représente désormais l'innovation et la modernité culturelle dans un monde dominé par les

pratiques Agiles. Cette culture est également porteuse de sens pour les dirigeants et les ingénieurs

confrontés quotidiennement à des problèmes structurels et relationnels.

Déterminer comment s'orchestre l'industrialisation des SI a constitué un véritable challenge.

L'engagement de nombreuses recherches bibliographiques et webographiques était nécessaire à la

bonne réalisation de ce mémoire. Le livre "Next Gen DevOps" de Grant Smith et les deux éditions de

"Continuous Delivery and DevOps : a Quickstart guide" de Paul Swartout ont fortement contribué. Je

me suis également appuyé sur d'autres sources : des webinars, des interviews, sur les cours


[2]

dispensés lors de ma formation d'Expert en Ingénierie Informatique et bien évidemment sur

l'immense base d'informations d’Internet. Ces sources m'ont permis de puiser l'inspiration pour

répondre aux interrogations soulevées tout au long de ce mémoire. Entre autres : Quels sont les

enjeux et les contraintes du mouvement DevOps ? Comment s'intègre-t-il dans les organisations

actuelles ? Comment s'articulent les directions des systèmes d'information modernes ? Quels sont

les moteurs de développement DevOps ? Peut-on réellement industrialiser les systèmes

d'information ? Au travers de toutes ces interrogations, ce mémoire orienté DevOps tend à

démontrer que les hommes et les outils sont en phase de transition vers une nouvelle manière de

mettre en œuvre l'informatique moderne. Ce premier bilan est positif et rempli d’espérance pour

que la voix vers l'automatisation totale des processus se construise lentement mais

progressivement.

Ce mémoire est constitué de trois parties successives. L'ouverture se compose d'un état de l'art de

DevOps, dans lequel nous retrouvons les fondements du mouvement et les concepts Agiles. Suivie

par une étude sur les rouages des DSI et de leurs complexités, qui offre une analyse organisationnelle

et relationnelle ainsi qu'une mise en avant de certaines théories de management liées aux directions

des systèmes d'information. Enfin ce mémoire se clôture par les chemins menant à l'industrialisation

des SI par DevOps, comprenant un guide d'outillage et des solutions adaptées à la conduite du

changement.


[3]

1. Etat de l’art du DevOps

1.1. DevOps, un mouvement, une culture

1.1.1. Objectif du mouvement

DevOps est une appellation issue de la contraction des mots anglais « Development » et

« Operations ». Les « Dev » représentent ainsi les services de développement d’une organisation,

s’opposants aux « Ops » qui représentent les services de production, à savoir les administrateurs et

les exploitants.

Il s’agit d’une tendance récente. L’idéologie a commencé à se dessiner en 2008 lors d’une conférence

Agile dispensée par Andrew Clay Shafer et Patrick Debois concernant les infrastructures Agile. Ces

deux protagonistes ont créé suite à cette conférence le « Agile Administrators Group on Google »,

qui donna naissance un an plus tard, en 2009, au terme DevOps que nous connaissons. Le terme a

notamment été popularisé par des journées spécialisées sur le sujet, les DevOps Day.

DevOps est donc un mouvement visant à fluidifier la coopération pour la mise en œuvre des

processus IT afin de générer une synergie entre les équipes de production et les équipes de

développement. Cette coopération vise à rectifier les faiblesses actuelles des services informatiques

sur leur communication, collaboration, intégration et automatisation des tâches. Plus qu’un simple

mouvement étique, DevOps est une méthode de développement permettant d’instaurer les bonnes

pratiques et un mode de conduite appropriés à l’entreprise.

Figure 1 : Représentation des acteurs DevOps

L’objectif global peut se résumer par la volonté de casser les barrières entre les deux fonctions des

DSI, à savoir les développeurs et les opérationnels. Pour mener à maturité cet objectif, plusieurs

thématiques sont abordées par les spécialistes DevOps, entre autres : rénovation des processus de

team building, optimisation de la communication, standardisation des mises en production,

normalisation du versionning, continuous delivery et stabilisation des infrastructures.

Developpeurs Opérationnels Autres

participants du projet

DevOps


[4]

Tous ces sujets abordés par la communauté DevOps cherchent à réinventer les pratiques

informatiques pour répondre au à un but collectif de chaque DSI : Gagner en compétitivité sur les

développements clients et internes sans perte de qualité.

1.1.2. La culture

Plus qu’un mouvement, DevOps apporte sa culture à l’entité informatique de l’organisation. Ainsi,

DevOps cultive les bonnes pratiques IT au travers de ses valeurs. Pour se faire, le seul moyen

d’obtenir des bénéfices de cette coopération est de sensibiliser l’ensemble des acteurs de la DSI, les

« Dev », les « Ops » mais aussi les managers. Comme toute culture, elle fonctionne seulement si tous

les membres jouent le jeu et la respecte pour remplir l’objectif final. DevOps touche ainsi la plupart

des acteurs d’un projet IT.

Figure 2 : Les acteurs d’un projet IT complexe

Comme évoqué, DevOps ne se résume pas seulement à la mise en place d’outils et processus dédiés,

mais se traduit par ses nombreuses valeurs traduisant une manière de travailler collectivement au

service d’une cause commune dépassant les objectifs personnels et d’équipe.

Manager

Developpeurs

Testeurs

Exploitants

Administrateurs

Architecte

Chef de produit

Chef de projet

Extensions (Marketing,

RH, etc.)


[5]

Figure 3 : Les valeurs de la culture DevOps

Transparence : l’avancement des tâches de chaque acteur du projet doit être clairement visible et ne

doit pas être masqué ou susceptible d’une mauvaise interprétation. Cet aspect permet de disposer

d’une vision concise sur l’état global d’un projet. C’est la seule façon de pouvoir anticiper les risques

de retards de livraison et la transparence encourage la solidarité entre les acteurs.

Encourager le changement : le changement est une composante inévitable dans le monde du

numérique. L’être humain a souvent tendance à être réfractaire à l’évolution car l’adaptation génère

un stresse inévitable pouvant interpréter par un risque d’échec possible. Or, le changement permet

d’améliorer et faire évoluer les services IT proposés. Une fois la période d’adaptation écoulée,

l’utilisateur final en retirera des bénéfices certains.

Encourager les bons comportements : étape cruciale pour améliorer les pratiques dispensées dans

l’organisation, les attitudes positives doivent procurer un sentiment de gratification pour l’acteur en

question.

Culture de l’innovation : l’innovation est l’essence même de l’informatique, c’est une valeur clé

destinée à encourager l’inventivité et l’ingéniosité dans la DSI. Il faut ainsi encourager les nouvelles

idées à aboutir afin de faire évoluer le SI avec l’entreprise dans son environnement.

Valeurs DevOps

Transparence

Encourager le changement

Encourager les bons

comportements

Culture de l'innovation

Responsabiliser les acteurs

Pas de blâme

Ne pas craindre l'échec

Confiance

Collaboration

Honnêteté et ouverture

d'esprit


[6]

Responsabiliser les acteurs : chaque collaborateur doit prendre conscience de ses responsabilités,

sans chercher à excuser ses erreurs. Une prise de responsabilité permet gain de maturité dans la

fonction exercée et met en avant les éventuelles faiblesses de travail à corriger.

Pas de blâme : il est nécessaire d’éviter l’apparition de règlements de comptes au sein d’une DSI. Le

fait de blâmer autrui pour ses erreurs créer un sentiment d’animosité provoquant un climat

accusateur et impropre à une bonne collaboration. De plus, la multiplication des blâmes entraine le

collaborateur dans une spirale émotionnelle négative impactant fortement son implication dans le

projet et endommageant ses performances sur le long terme. Plus le collaborateur se sentira

incompétent, plus ses résultats tendront à la baisse.

Ne pas craindre l’échec : la peur de l’échec constitue un frein à l’évolution. Elle positionne le

collaborateur dans une zone de confort. Elle constitue par conséquent un frein à l’évolution qui n’est

pas acceptable dans une DSI puisque seule la prise de risques permet d’améliorer les structures

actuelles.

Confiance : un climat de confiance fluidifie l’interaction interservices au sein d’un projet. C’est une

étape indispensable pour obtenir une coopération efficace entre les participants. De plus, elle

permet se dispenser de vérifications inutiles qui peuvent générer d’importante pertes de temps. Le

temps passé à vérifier le travail d’un autre acteur est du temps perdu sur l’avancement de ses

propres tâches.

Collaboration : il est important que chaque partie prenante dans l’organisation de la DSI apprenne à

collaborer avec les autres acteurs de façon sereine. Alors que les développeurs souhaitent à tout prix

diffuser de nouvelles fonctionnalités, les services de production essayent de freiner les

multiplications des mises en production afin de maintenir une infrastructure stable. Une

collaboration efficiente consiste à réunir ces deux parties pour trouver l’équilibre tout en assurant le

développement continu des applications.

Honnêteté et ouverture d’esprit : l’honnêteté fonctionne de pair avec la transparence. Elle permet

d’obtenir une justesse dans l’équilibrage des rôles. C’est une façon de se concentrer sur le cœur

d’activité avec facilité. L’ouverture d’esprit offre à l’organisation une meilleure écoute de

l’environnement au service des opportunités d’évolution.


[7]

De façon exhaustive, la culture Devops englobe les outils et la technicité, la standardisation des

processus, les comportements internes, la communication interservices et l’environnement IT.

Figure 4 : Représentation graphique de la culture DevOps

Il est à noter que la culture DevOps évolue et mute très rapidement. La communauté étant

grandissante, les acteurs sont à l’écoute des nouvelles opportunités et de l’évolution du monde

numérique. Il n’y a aucune rigidité dans la pratique DevOps car il s’agit avant de bon sens issu du fruit

de réflexions d’un collectif d’administrateurs férus de méthodes Agiles.

1.1.3. Les apports de DevOps

Les bénéfices de l’intégration de la culture DevOps dans une organisation interne sont nombreux.

Concrètement DevOps permet d’agir directement sur la productivité des développeurs et des

administrateurs systèmes, sur la qualité du SI mais aussi d’améliorer les relations sociales tout en

réduisant les coûts liés au SI.

L’atout le plus avantageux de DevOps concerne la productivité. D’une part les développeurs ont la

possibilité de mettre à jour leurs applications plus régulièrement en passant par moins de procédures

manuelles chronophages. D’autre part les administrateurs systèmes pourront se concentrer sur

l’évolution des infrastructures et l’intégration de nouveaux projets IT car ils économiseront en

manipulations répétitives. Cette productivité est possible car DevOps cherche à fluidifier les

échanges internes entre les développeurs et les opérationnels. De plus DevOps vise à automatiser au

maximum toutes les étapes manuelles superflues. Des outils DevOps permettent aux acteurs IT de

faciliter cette vision et de la mettre en œuvre facilement.

Culture DevOps

Outils et technicité

Standardisation des processus

Comportements internes

Communication interservices

Environnement IT


[8]

Concernant l’amélioration globale de la qualité du SI, DevOps agit sur les tests et la

responsabilisation des acteurs. Les tests sont poussés à leur maximum au travers de la mise en place

semi-automatique mais méthodique de vérifications sur chaque fonctionnalité, service et serveur

déployé en production. Par ailleurs la responsabilisation des acteurs est une valeur clé de DevOps qui

consiste à faire prendre consciences aux participants des projets qu’ils doivent agir et prendre des

décisions basées sur des faits. Ainsi chaque participant devra assumer ses choix, aussi bien en cas de

réussite que d’échec. Dans cette culture il n’est pas toléré de blâmer autrui pour ses propres erreurs.

Les collaborateurs redoublent donc de patience et de précautions.

De plus, une bonne intégration des pratiques DevOps améliorera sensiblement les relations

interservices dans l’organisation. Au travers de ses valeurs de confiance, de transparence, de

collaboration, d’honnêteté et de précautions vis-à-vis du blâme DevOps prône une bonne entente

entre toutes les parties d’un projet ou d’une structure. C’est une étape essentielle de cette culture

sans laquelle le reste des valeurs ne peut être totalement réalisé.

Enfin, DevOps permet de réduire les coûts liés au SI. Grâce à l’amélioration de la productivité, les

développeurs peuvent produire plus d’applications. Sur le long terme, le recrutement de

développeurs pourra donc diminuer. Les administrateurs systèmes et exploitants sont également

concernés puisque l’exercice de leur travail se simplifie grandement. La mise en place d’une culture

DevOps peut se résumer en un investissement à long terme. Les coûts et les efforts liés à

l’intégration de DevOps peuvent être conséquents mais le résultat final apporte en retour de

nombreux avantage et une économie sur un plan de ressources humaines.

Figure 5 : Enquête de Vanson Bourne, 2013 - les bénéfices de DevOps observés par 1300 décideurs IT de 21 pays

0% 10% 20% 30% 40% 50% 60%

Déploiements plus fréquents des logiciels et services

Plus grande collaborations entre les départements

Réduction des dépenses IT

Disponiblité sur plusieurs plateformes

Amélioration de la qualité logicielle

Moins de main d'œuvre IT

Des logiciels qui auraient étés impossible de lancer

Hausse du nombre d'utilisateurs de logiciels

Réduction du time-to-market

Une augmentation du chiffre d'affaire

Les bénéfices de DevOps observés sur le terrain


[9]

1.1.4. Les DevOps Days

Comme son nom l’indique, les DevOps Days sont des journées dédiées aux pratiques DevOps. Elles

sont animées par les principaux acteurs précurseurs du mouvement, tel que The Velocity

Conference, afin de répandre ces pratiques à travers le monde.

Lors de ces conférences nous pouvons assister à la présentation des nouveaux outils DevOps et à des

démonstrations d’utilisation, mais aussi à l’actualité du mouvement, les innovations à venir, des

témoignages de certains géants du web, des conseils d’intégration, des réflexions sur le thème et des

moments d’échanges, de réflexion, de débats sur ces pratiques.

La première conférence a eu lieu en 2009 en Belgique, elles sont désormais fréquentes et dispensées

partout dans le monde et dans toutes les capitales technologiques.

De plus, l’intégralité des conférences référencées en tant que DevOps Days sont mises à dispositions

sous format vidéo gratuitement sur la plateforme Vimeo. Il est ainsi possible de suivre l’évolution de

ces technologies et de prendre part à l’évolution du mouvement très simplement.

Figure 6 : Planning des DevOps Days par www.devopsdays.org

1.2. Une approche pragmatique

1.2.1. Introspection sur l’origine du mouvement

Le constat d’une complexification de l’IT : les outils et processus informatiques évoluent avec le

développement du numérique, ce qui provoque une complexification inévitable des méthodes de

développement. De plus, le grandissement constant des services informatiques des sociétés, qui


[10]

prennent conscience de l’importance des enjeux liés à la performance du SI, ajoute une nouvelle

complexité dans la gestion des projets. Ainsi, la livraison d’un nouveau produit ou l’ajout d’une

nouvelle fonctionnalité nécessite de mobiliser de plus en plus d’acteurs. Il faut donc canaliser et

optimiser les échanges interservices au sein d’un projet. Cette complexification entraine donc une

mutation des processus de développement et de mise en production vers des flux de travail plus

détaillés.

Figure 7 : Processus de développements ACME logiciels - version 1.0


Avoir une idée

La développer

La déployer

Avoir une bonne idée

En débatre

Obtenir l'accord de développement

Définir les exigence environnementales

Le developper

Procéder aux tests

Corriger les bugs

Planifier les release

Rédiger les documents

d'exploitations

Valider la documentation

Tester les release

Corriger les bugs

Déployer la release

Corriger les bugs


[11]


L’arrivée du Cloud : ce bouleversement IT a radicalement modifié la façon de proposer des produits

et des services aux clients. Tandis que le modèle traditionnel consistait à réaliser un produit en

suivant un cahier des charges définit conjointement avec le client, le Cloud fonctionne sur un modèle

de développement bien différent, celui du SaaS. Le client n’exprime plus une demande précise mais

loue les services du fournisseur lui semblant le plus pertinent par rapport à ses attentes. Il est bien

sûr possible d’exprimer des remontées d’utilisation ou de financer des développements spécifiques,

cependant le modèle économique s’exprime essentiellement par le volume d’utilisateurs qui offre à

la plateforme toute sa crédibilité en offrant une puissance commerciale donnée pour la société. Le

mouvement DevOps permet ainsi de répondre plus efficacement à ce nouveau modèle économique

par la rapidité et la stabilisation des développements réalisés. Il est ainsi possible de mettre à jour

fréquemment une application sans perturber la stabilité des infrastructures.

Une intensification du contexte économique concurrentiel : l’essor des géants du web ainsi que les

restrictions budgétaires liées à un contexte économique international fortement intensifié par la

globalisation industrielle et tertiaire a conduit l’entreprise à optimiser leurs services informatiques

afin de produire plus, sur de meilleures bases d’infrastructure tout en réduisant au maximum les

coûts d‘infrastructures. La rapidité de développement est également remise en cause et les

entreprises cherchent désormais à gagner en productivité en sélectionnant attentivement leur

Avoir une bonne idée

Rédiger les tests

Le développer

Procéder aux tests

L'intégrer

Le déployer

Le superviser

Récupérer les retours


[12]

langage de programmation et les conditions de travail octroyées aux développeurs. DevOps permet

encore une fois d’agir directement sur cette problématique au travers de ses valeurs et en offrant

une automatisation des processus répétitifs dans les services informatiques.

L’essor de la mobilité : la mobilité ajoute une nouvelle composante dans la gestion des

infrastructures et du développement : les problématiques de compatibilité multiplateformes. Il est

maintenant nécessaire d’assurer du bon fonctionnement applicatif sur de nombreux systèmes. Ce

nouvel aspect entraine donc une forte intensification des tests à réaliser. De plus, une

standardisation des processus développements doit être mise en place afin de pallier à des

éventuelles erreurs humaines de compatibilité. Pour cela, DevOps assiste les développeurs dans leur

mission et permet d’automatiser intégralement le workflow de mise en production.

Une fragmentation des DSI sous forme de silos : les organisations internes des services

informatiques sont pour la plupart organisées sous forme de cellules distinctes, devant collaborer

ensemble mais avec des objectifs différents. On parle alors de silos car les équipes sont chacune

étanches aux demandes des autres et sont donc peu attentives aux besoins des collaborateurs.

DevOps tente de répondre à cette problématique par ses valeurs de transparence, de collaboration

et de confiance.

1.2.2. Une pratique collective

Comme évoqué précédemment, DevOps n’offre pas une réponse ciblée sur une ou plusieurs parties

d’une entité informatique mais agit sur sa globalité. S’il n’est aucunement impératif de respecter la

totalité des pratiques dispensées par le mouvement, la réussite d’une intégration DevOps passera

par la sensibilisation de tous les acteurs de la DSI.

Les exemples de réussite des principaux acteurs actuels démontrent que les succès des pratiques

DevOps se ressentent lorsque la culture est parfaitement assimilée par la totalité de la DSI. Le respect

des procédures représente une de ces composantes dominantes. Ainsi, la prise de risque est

considérable lorsque des collaborateurs ne respectent pas les consignes indiquées dans les

référentiels DevOps en vigueur dans l’entreprise et les impacts peuvent être destructeurs à effet


[13]

immédiat ou différé par la présence d’un bug non détecté ou l’ajout d’une brique non contrôlée à la

structure du SI.

Par ailleurs, une des volontés du changement proposée par DevOps concerne les échanges

interservices. Il serait néfaste à l’intégration des pratiques DevOps qu’une ou plusieurs cellules de

travail opposent une résistance par rapport à ces pratiques. Si nous partons du constat simple que

certains collaborateurs possèdent une qualité intra personnelle les incitants à rester dans leur zone

de confort, cet aspect peut être facilement maitrisé par un apprentissage mesuré. Cependant, si

l’idéologie même des pratiques DevOps rebute une majorité des acteurs et affecte totalement

certaines équipes, les bénéfices apportés à la DSI seront fortement minimisés et le processus

d’intégration sera allongé. D’autant plus que cela impactera le reste des collaborateurs en diminuant

leur motivation par rapport à l’application des consignes en vigueur.

Enfin, il ne faut pas perdre de vue que DevOps est avant tout un mouvement fondé sur le bon sens

d’une réflexion communautaire globale. Ce qui signifie que si les valeurs ne sont pas partagées par

l’ensemble des collaborateurs de la DSI le changement n’est peut-être pas opportun ou les pratiques

ne peuvent peut être tout simplement pas s’adapter aux conditions de travail de l’entité.

1.3. Un complément des méthodes Agiles

1.3.1. Définition des méthodes Agiles

On décrit parfois DevOps comme le « chainon manquant des méthodes Agiles ». Les méthodes Agiles

sont des groupes de pratiques portées sur les projets en conception logicielle. Ces pratiques sont

référencées au travers de l’Agile manifesto, un recueil co-rédigé en 2001 par 17 grands acteurs du

domaine informatique qui a popularisé le terme « Agile ». Les méthodes Agile impliquent au

maximum le client et permettent de lui offrir une grande rapidité de traitement de ses demandes.

Toutefois le nom de méthodes Agiles est considéré comme fortement réducteur puisqu’il ne s’agit

pas uniquement d’une simple méthode de développement car elle apporte également une approche

sur la gestion de produits, la communication et la satisfaction cliente. On parle alors d’état d’esprit

Agile, de culture Agile ou encore de courant Agile.

Concrètement, la vision de la gestion de projet est remplacée par la gestion de produits, car l’objectif

final d’un projet est de donner naissance à un produit. Cet aspect a été définit en réaction des

approches traditionnelles devenues inadaptées qui consistaient à répondre techniquement à un


[14]

cahier des charges définit par le client, à développer le produit sans mesure temporelle puis à livrer

le produit pour la phase de recettage. On parle ici d’effet tunnel qui peut générer des conflits avec le

client et créer un déphasage entre le besoin initial du demandeur et l’application réalisée. En effet, le

client pense le produit, l’exprime dans ses mots d’une façon qu’il estime suffisamment précise et la

société de développement réalise la demande en interprétant le cahier des charges. Toutefois,

l’expérience a démontré que le client exprime la quasi-totalité du temps de la frustration et de la

déception lors de la première utilisation de son produit car le résultat est différent de ce qu’il avait

imaginé, et cela même si tous les points du cahier des charges ont été scrupuleusement respectés.

Entre autres, la méthode Agile définit des jalons préalablement déterminés avec le client pour valider

les développements en cours.

Figure 10 : Exemple d'application de la méthodologie Agile en mode Scrum par l'entreprise Esker

Pour se faire, les méthodes Agiles sont répertoriées en 4 valeurs et 12 principes généraux. Les valeurs

définissent les axes fondamentaux sur laquelle la méthode repose tandis que les principes détaillent

de façon plus précise les règles à respecter. Pour qu’une méthode soit considérée en tant qu’agile,

elle doit respecter tous les principes et donc par extension se conformer aux 4 valeurs également.

Les 4 valeurs :

- L’équipe : (« Les individus et leurs interactions, plus que les processus et les outils ») : dans

l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle)

ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui

communique, composée de développeurs (éventuellement à niveaux variables), plutôt


[15]

qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La

communication est une notion fondamentale.

- L’application : (« Des logiciels opérationnels, plus qu'une documentation exhaustive ») : il est

vital que l'application fonctionne. Le reste, et notamment la documentation technique, est

une aide précieuse mais non un but en soi. Une documentation précise est utile comme

moyen de communication. La documentation représente une charge de travail importante,

mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter

abondamment le code lui-même, et surtout de transférer les compétences au sein de

l'équipe (on en revient à l'importance de la communication).

- La collaboration : (« La collaboration avec les clients, plus que la négociation

contractuelle ») : le client doit être impliqué dans le développement. On ne peut se

contenter de négocier un contrat au début du projet, puis de négliger les demandes du

client. Le client doit collaborer avec l'équipe et fournir un compte rendu continu sur

l'adéquation du logiciel avec ses attentes.

- L’acceptation du changement : (« L'adaptation au changement, plus que le suivi d'un

plan ») : la planification initiale et la structure du logiciel doivent être flexibles afin de

permettre l'évolution de la demande du client tout au long du projet. Les premières

livraisons du logiciel vont souvent provoquer des demandes d'évolution.

Les 12 principes :

- Principe n°1 : La plus haute priorité est de satisfaire le client en livrant rapidement et

régulièrement des fonctionnalités à forte valeur ajoutée.

- Principe n°2 : Le changement est accepté, même tardivement dans le développement, car les

processus agiles exploitent le changement comme avantage concurrentiel pour le client.

- Principe n°3 : La livraison s’applique à une application fonctionnelle, toutes les deux

semaines à deux mois, avec une préférence pour la période la plus courte.

- Principe n°4 : Le métier et les développeurs doivent collaborer régulièrement et de

préférence quotidiennement au projet.

- Principe n°5 : Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement

et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.

- Principe n°6 : La méthode la plus efficace pour transmettre l'information est une

conversation en face à face.

- Principe n°7 : L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui

exclut de comptabiliser les fonctions non formellement achevées).


[16]

- Principe n°8 : Les processus agiles promeuvent un rythme de développement soutenable

(afin d’éviter la non qualité découlant de la fatigue).

- Principe n°9 : Les processus agiles recommandent une attention continue à l'excellence

technique et à la qualité de la conception.

- Principe n°10 : La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme

principes essentiels.

- Principe n°11 : Les équipes s'auto-organisent afin de faire émerger les meilleures

architectures, spécifications et conceptions.

- Principe n°12 : À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace,

puis accorde et ajuste son processus de travail en conséquence.

1.3.2. Les méthodes dites Agiles

Depuis la publication de l’Agile manifesto en 1991, plusieurs méthodes se sont conformées aux

valeurs et principes Agile. Nous pouvons en dénombrer 3 principales qui sont très largement

répandues dans le monde du développement logiciel.

RAD (développement rapide d’applications) : Décrite pour la première fois en 1991 par James

Martin, cette méthode présente une méthodologie idéale pour développer rapidement des

applications. D’après son auteur, la méthode apporte 3 avantages compétitifs à l’entreprise : une

rapidité de développement, un faible coût de production et une amélioration de la qualité de

l’application. La méthode se fonde sur quatre principes fondamentaux :

- Les outils utilisés pour le développement : conception, prototypage, génération de code. Ils

sont détaillés dans un référentiel.

- Les personnes intégrées aux projets doivent être compétentes, expérimentées et motivées.

- Le management de la gestion de projet doit être mis en avant tout en évitant d’être

confronté à un mode bureaucratique trop exacerbé.

- La méthodologie utilisée se doit d’être à la fois bien formalisée et souple.

De nombreux principes sont également abordés tels que la spécialisation des rôles, les formalisations

de processus ou encore l’organisation des divers types de réunions.


[17]

Cette méthode a été très largement utilisée dans les années 90, c’est également la première

méthode qualifiée en d’Agile. Toutefois la tendance montre qu’elle est parfois délaissée au profit de

Scrum et XP qui sont plus récentes.

Scrum : Il s’agit d’une pratique, créée par Jeff Sutherland et Ken Schwaber en 2004 dans l’Agile

Software Management With Scrum, par laquelle le développement est échelonné par une fréquence

de jalons très soutenue. On retrouve aujourd’hui la méthode Scrum dans plus de 50% des projets dits

Agiles. Tout comme la précédente, cette méthode repose sur quatre principes fondamentaux

(citations de Jeff Shutherland extraites de son manifeste pour le développement agile de logiciels) :

- La planification est utile : "Il est tellement tentant de dresser des plans sans fin, de détailler à

l'envi tout le travail qui doit être accompli sur un projet massif... mais lorsque les plans

détaillés ne correspondent pas à la réalité, ils s'effondrent. Incluez dans votre méthode de

travail l'hypothèse du changement, de la découverte et de nouvelles idées."

- Inspecter et adapter : "De temps en temps, interrompez ce que vous êtes en train de faire,

revoyez ce que vous avez fait et déterminez si c'est toujours ce que vous devez faire et si vous

pouvez le faire mieux."

- Changer ou disparaître : "S'accrocher à l'ancienne manière de procéder et à l'ancien système

de commandement et de contrôle et de prévisibilité rigide ne fera que précipiter l'échec.

Pendant ce temps, les concurrents qui sont prêts à changer vous laisseront mordre la

poussière."

- Echouer rapidement pour pouvoir corriger au plus tôt : "La culture d'entreprise accorde

souvent plus de poids aux formulaires, procédures et réunions qu'à la création de valeur

visible qui peut être inspectée à intervalles courts par les utilisateurs. Tout travail qui ne

produit pas une valeur réelle est une folie. En travaillant sur les produits par cycles courts,

vous pouvez obtenir au plus tôt les réactions des utilisateurs et éliminer immédiatement les

efforts qui ne servent manifestement à rien."

De plus, Scrum repose sur trois piliers :

- La transparence : Scrum met en avant la communication entre les managers et leurs équipes

afin de pouvoir accéder rapidement à une bonne compréhension de l’état global du projet.

- L’inspection : Un point d’inspection régulier doit être instauré et réalisé avec un inspecteur

compétent.

- L’adaptation : Si un défaut est constaté lors de l’inspection, le développement en cours déjà

réalisé doit être revu puis adapté.


[18]

Cependant la méthode est difficile à appliquer et les projets ont tout de même tendance à être

rendus en retard et dans une situation de dépassement budgétaire. A la fin d’un sprint de

développement, plus de 80% des équipes ne testent pas si les logiciels fonctionnent ou ne réalisent

pas des tests complets sur les nouvelles fonctionnalités produites.

XP (eXtreme Programming) : en génie logiciel, cette méthode détaille des bonnes pratiques sur la

réalisation d’une application tout en incluant une composante de gestion de projet. Elle s’adapte

tout particulièrement aux équipes à effectifs réduits dotées de besoins variables. Comme son nom

l’indique, elle pousse à l’extrême des principes de programmation simples. La méthode a été

inventée par Ken Beck, Ward Cunningham et Ron Jeffries en 1999 au travers du livre Extreme

Programming Explained.

La méthode repose sur cinq valeurs fondamentales :

- La communication : elle oblige les développeurs, les décideurs et les clients à communiquer

au travers des tests, de la programmation en binôme (travaille commun de deux

développeurs exécuté sur un seul poste de travail) et par la tenue du planning.

- La simplicité : Ken Beck part du principe que la façon la plus simple d’arriver au résultat est la

meilleure. Une trop forte anticipation est selon lui une perte de temps délibérée.

- Le feedback : le retour d’information sur un développement est primordial pour le

programmeur et le client. Le feedback est ainsi porté sur les tests unitaires et les tests

fonctionnels.

- Le courage : il concerne la motivation de changer l’existant en cours de phase de

développement. Par extension il permet de sortir d’une situation inadaptée.

- Le respect : ajouté dans le référentiel dans sa deuxième version, cette valeur traite du

respect envers le client et les proches collaborateurs.

Ces valeurs se déclinent également en treize pratiques complémentaires :

- Client sur site : dans une situation idéale, un représentant du client doit se rendre

physiquement sur site durant toute la durée du projet pour répondre aux questions des

développeurs.

- Jeu du Planning ou (Planning Poker) : le client doit fournir des scénarios d’utilisation sur les

fonctionnalités dont il souhaite disposer. Une fois la tâche accomplie, le temps de

développement estimé pour chaque tâche est proposé au client qui priorise ensuite les

développements en fonction du capital temps dont il dispose.


[19]

- Intégration continue : elle consiste à intégrer au corps du programme une fonctionnalité dès

lors qu’elle a été développée en vue d’éviter toute surcharge de travail d’intégration.

- Petites livraisons : la multiplication des livraisons doit se dérouler le plus fréquemment

possible dans l’optique de réduire les coûts relatifs à la livraison.

- Rythme soutenable : l’équipe de développement ne doit pas faire d’heures supplémentaires

car un développeur fatigué est moins performant. Il est ainsi impensable de fournir un

logiciel de moindre qualité au client.

- Tests de recette : en fonction des scénarios d’utilisation fournis par le client, des procédures

de tests sont rédigées puis automatisées dans la mesure du possible. Cette tâche est parfois

confiée à un collaborateur dont cette partie en constitue la mission principale.

- Tests unitaires : au minimum un test doit être réalisé pour chaque fonctionnalité et conservé

durant toute la durée du projet. Cette partie apporte de l’exhaustivité dans la réalisation des

tests unitaires avant les rendus planifiés et la livraison finale.

- Conception simple : imaginer les prochaines évolutions est une perte de temps sans garantie

de retirer un bénéfice ultérieur. Par conséquent, concevoir une application très simple

facilitera inévitablement les futures itérations

- Utilisation de métaphores : l’utilisation d’images verbales, à la place de termes techniques

pointus, pour décrire le fonctionnement du système est préconisée pour faciliter la

compréhension.

- Refactoring : le factoring est un remaniement du code destiné à améliorer régulièrement le

code sans en modifier le comportement. Cela permet de restructurer les fondations d’une

application en vue de l’ajout de nouvelles fonctionnalités. Ce principe fonctionne

conjointement avec le principe de conception simple dans un souci de gain de temps. Il faut

donc toujours développer l’application simplement sans anticiper les évolutions éventuelles

et lorsque le besoin se présente adapter le code applicatif en fonction des nouvelles

demandes.

- Appropriation collective du code : l’équipe est collectivement responsable de l’application.

Cela signifie qu’un développeur pourra apporter une modification à une fonctionnalité qu’il

n’aura pas développée personnellement.

- Convention de nommage : selon le principe précédant, il est impératif de définir une

nomenclature commune et de la respecter attentivement.

- Programmation en binôme : les sessions de développement sont réalisées en binôme

composés d’un « driver », qui utilise le clavier pour programmer, et d’un « partner » qui lui

suggère de nouvelles fonctionnalités et qui détecte en temps réel les possibles bugs. Un


[20]

driver doit changer régulièrement de partenaire pour améliorer la connaissance du produit

et la communication au sein de l’équipe.

Enfin, plusieurs méthodes moins rependues sont également considérées comme Agiles :

- DSDM : Dynamic Systems Development method (dérivée du RAD)

- ASD : Adaptative Software Development (dérivée du RAD)

- FDD : Feature Driven Development (dérivée du RAD)

- RUP : Rational Unified Process

1.3.3. Les limites des méthodes Agiles

Les méthodes Agiles proposent des bonnes pratiques informatiques. Si effectivement ces dernières

sont pensées pour améliorer les techniques de travail actuelles, leur application stricte peut en

fonction des situations générer d’autres problèmes. Un ré-ajustage palliatif devrait alors être intégré

pour combler les lacunes rencontrées. Il faut tout de même noter que ces limitations sont parfois

comblées par des extensions de la méthode, telles que Scrum ou XP. Mais aucune méthode n’est à ce

jour jugée comme infaillible.

Tout d’abord, un déséquilibre est constaté dans les organisations entre les équipes Agiles et les

autres. Ce point concerne en partie la documentation produit. Selon Agile, il est préférable de

diminuer la production de document au profit de plus de commentaires dans le code source lui-

même. Les équipes de productions peuvent être déstabilisées par ce manque fictionnel de

documentation, ou en cas de reprise du projet par un service non Agile, la prise de connaissance sur

le projet serait fortement freinée.

De plus les méthodes Agiles sont portées sur une vision de développement pure et parfois sur le

client, cependant elles excluent la production et les autres participants du projet. Il en résulte un

manque d’exhaustivité sur la gestion du projet qui ne peut ainsi se dérouler parfaitement bien.

Sachant qu’un projet IT ne se limite pas qu’à son simple développement logiciel, il est désormais

indispensable de prendre en compte le maximum de paramètres concernant ce dernier pour

s’assurer de sa bonne exécution tout au long de la durée de vie du produit. Le développeur ne peut

plus continuer à exercer seul mais doit prendre en compte l’ensemble des autres intervenants.

Selon le principe n°11 du manifeste, les équipes de développement s’auto-organisent. Par extension,

elles doivent réguler leur apprentissage tout en assurant le développement applicatif. Ce point


[21]

demande aux équipes d’être très rigoureuses pour ne pas se laisser déborder sur le planning de

livraison. En effet, si les équipes ont un ratio de formation par rapport à la production trop

conséquent le retard s’accumulera et les délais ne seront pas respectés. Le client sera donc contrarié,

ce qui va à l’encontre des valeurs fondamentales d’Agile qui visent avant tout à satisfaire le client

final.

Par ailleurs la pratique des méthodes Agiles nécessite une implication importante du client dans le

projet mais aussi une compréhension du fonctionnement de la méthode. Toutefois il peut arriver que

le client ne saisisse pas concrètement l’intérêt du mode de partenariat client/fournisseur préconisé

ou qu’il ne puisse pas assurer son rôle à cause des ressources en sa possession. Démarrer un projet

Agile sans le soutient ou le total investissement du client provoquera une forte probabilité d’échec.

Enfin, la pratique des méthodes Agiles entrainent une modification de la manière de négocier le

contrat avec le client. Il n’est pas envisageable d’établir une tarification du projet préalablement à

son développement, ni de fixer une date de livraison précise. Or la majorité des clients ne souhaitent

pas être confrontés à une incertitude au sujet des délais et des tarifs puisqu’il souhaite sélectionner

le meilleur partenaire pour son projet principalement en fonction de ces deux informations. Ce point

est vraisemblablement le plus rebutant pour les clients ne maitrisant pas les concepts de gestion de

projets Agiles.

1.4. Un complément au « continuous delivery »

1.4.1. Définition du « continuous delivery »

Le « continuous delivery » est une approche en génie logicielle consistant à produire une application

fonctionnelle en courts cycles de développement afin de s’assurer de la qualité et de la fiabilité du

système à tout moment. Cette approche permet alors d’automatiser et améliorer les livraisons pour

le client.

Figur : Processus de « Continuous Development »

Production du développement

Auto Tests unitaires Auto Intégration Auto Tests

d'acceptation Manuel

Déploiement en production


[22]

Lorsque que l’on évoque le « continuous delivery », le terme « continuous deployment » est souvent

évoqué. On distingue donc le déploiement de la livraison du produit. Le « continuous deployment »

concerne la mise en production de chaque changement apporté à la l’application. Et ils sont

effectivement nombreux, ce qui soulève inévitablement des problématiques d’adaptation de la part

des services de production (erreurs humaines, compatibilité environnementale, packaging de

l’application, évolution précipitée des infrastructures, etc.). Il est alors nécessaire de garder une

cohérence sur la rapidité d’exécution des deux parties, l’un ne doit pas ralentir l’autre sous peine de

compromettre l’intégralité de l’approche.

Figure 11 : Processus de « Continuous Deployment »

L’objectif du « continuous deployment » et du « continuous development » est d’automatiser au

maximum tous les enchainements de tâches qui composent le cycle de vie de production d’une

application. Cette automatisation permet de diminuer considérablement les manipulations humaines

et donc de dégager du temps de travail pour se concentrer uniquement sur la programmation de

l’application.

Figure 12 : Composantes du « Continuous Delivery »

Le développeur obtient ainsi une maitrise quasi-intégrale dans la chaine de mise en production, ce

qui permet d’apporter un rythme très soutenu de mise à jour. Cette approche s’adapte

particulièrement bien aux infrastructures de type client-serveur car l’application repose sur une

plateforme centralisée sur laquelle se connectent tous les utilisateurs finaux. La mise en production

devient donc une chose facile et peu risquée.

Il est tout de même important de relever que cette approche nécessite une grande rigueur de la part

du développeur. Il se doit d’assumer l’entière responsabilité du bon fonctionnement du produit. De

Production du développement

Auto Tests unitaires Auto Intégration Auto Tests

d'acceptation Auto

Déploiement en production

Continuous Development

Continuous Deployment

Continuous Delivery (CD)


[23]

plus les tests doivent être conçus avec une attention particulière de façon à être exhaustifs. Le cas

échéants, de nombreux dysfonctionnements applicatifs non détectés par le système automatique

provoqueraient alors une baisse de qualité importante. Néanmoins, de nouvelles techniques de tests

permettent aujourd’hui d’automatiser les vérifications sur chaque fonction, chaque service et chaque

composant de l’application.

Ainsi, le CD suit les nombreux principes de l’automatisation :

- Ne pas installer manuellement les dépendances logicielles ;

- Automatiser la construction des builds ;

- Automatiser les tests ;

- Appliquer un minimum de configurations manuelles ;

- Ne pas créer de machines manuellement ;

- Ne pas intervenir pour les livraisons ;

- Automatiser la supervision ;

- Utiliser un portefeuille de métriques de performances.

1.4.2. Cohésion de DevOps avec le « continuous delivery »

DevOps est un mouvement et le « continuous delivery » est une approche de développement

globale. Ces deux idéologies peuvent être compatibles entre elles et se rejoignent sur de nombreux

points : l’encouragement du changement, la responsabilisation des acteurs, ne pas craindre l’échec,

la culture de l’innovation et la transparence.

Il est alors envisageable de générer une synergie en appliquant les principes de ces deux techniques

dans la DSI. DevOps comblera l’incomplétude d’informations apportées par l’approche du CD sur les

principes de collaboration interservices et définira avec plus de finesse les intérêts communs à la DSI.

La vision du « continuous delivery » est plus restreinte mais concentrée sur la conception logicielle

tandis que la vision DevOps est globale mais plus idéologique.


[24]

Figure 13 : Représentation de l'association du « Continuous Delivery » et de DevOps

Cependant ces deux idéologies s’opposent sur certains points concernant les façons de collaborer.

Tandis que DevOps se concentre sur la collaboration interservices, le « continuous delivery » cherche

à mettre le développeur sur un plan central tout en diminuant le nombre d’acteurs. On oppose alors

un principe de collaboration contre un principe de centralisation, même si pour le CD les acteurs du

côté opérationnels doivent assurer leur rôle, il est réduit au maximum.

Les géants du web ont souvent recourt à l’utilisation de ces deux pratiques, combinées à d’autres

méthodes. On rencontre alors des entreprises de toutes tailles multipliant l’utilisation de pratiques et

d’idéologies selon leur philosophie en pratiquant par exemple simultanément les méthodes Scrum,

Agiles et/ou ITIL avec une idéologie DevOps influencée par l’approche du CD.

1.5. Les outils DevOps

1.5.1. Gestionnaires de configurations serveurs

DevOps est certes une idéologie avant tout, mais son intégration dans une société passe aussi par

l’utilisation de logiciels adaptés. Les gestionnaires de configurations sont essentiels à la pratique de

DevOps. Ils permettent de déployer des fichiers de configurations sur un ou plusieurs serveurs

simultanément. Ils permettent ainsi de réduire considérablement le temps dépensé par les

administrateurs systèmes et réseaux sur les installations et les évolutions du parc de serveurs.

Par ailleurs, plus le nombre de serveurs utilisés dans une société est élevé, plus l’intégration de ces

outils est judicieuse. En effet, l’utilisation de ce type d’outil permet de gagner en efficacité et en


[25]

homogénéité. Le temps utilisé pour mettre à jour deux cents serveurs deviendra donc le même que

pour un seul. L’administrateur sera certain que la configuration sera absolument identique sur toutes

les machines. Le risque d’erreur humaine devient par conséquent quasiment nul. Certains outils sont

également utilisables pour configurer des équipements réseaux tels que des commutateurs ou des

routeurs.

Il existe de nombreux outils sur le marché pour répondre à ce besoin. Les plus connus sont Chef,

CFEngine, Puppet et Ansible. Ils s’inscrivent directement dans le portefeuille de compétences des

ingénieurs DevOps et des administrateurs systèmes. La plupart de ces outils sont gratuits ou open

source. Pour plus d’informations, l’annexe 1 offre une liste détaillée des outils DevOps actuels.

1.5.2. Outils d’intégration continue

Les outils d’intégration continue permettent d’agir sur les aspects de « continuous development » et

de « continuous deployment ». Ils permettent de pousser l’automatisation des processus au

maximum afin de gagner en productivité. Pour cela, ils articulent les déploiements et les tests des

applications lors de la phase de développement. Il s’agit en quelque sorte d’un assistant de

développement traitant les tâches annexes de développement.

Ce type d’outils concerne principalement les développeurs qui en sont les principaux utilisateurs.

Grâce à ces outils, les développeurs peuvent se concentrer pleinement sur leur cœur de métier, le

développement d’applications.

Par ailleurs, la mise en production des logiciels est généralement chronophage et nécessite parfois de

collaborer avec un opérationnel. Désormais, avec des outils d’intégrations continues adéquates, le

développeur pourra maitriser cette partie et multiplier les déploiements applicatifs. Il gagne donc en

confort de travail et en autonomie.

Les outils de cette catégorie les plus connus sont Docker, Ansible, Puppet et Jenkins. La plupart de

ces solutions sont open source et gratuites. Pour plus d’informations, l’annexe 1 offre une liste

détaillée des outils DevOps actuels.


[26]

1.5.3. Outils de supervision

Les outils de supervision, également appelés outils de monitoring en anglais francisé, sont des

plateformes de contrôle du SI. Ils permettent de surveiller le bon fonctionnement d’un système

d’exploitation, d’un équipement matériel, de services Windows ou démons Linux, de processus, de

requêtes, de bases de données, de sauvegardes, etc. En cas de dysfonctionnement, une alerte est

automatiquement mise en évidence dans le panneau de contrôle et peut également être envoyée

par mail, sms, notification ou appel téléphonique.

Ce type d’outil est indispensable. S’il ne permet pas de gagner en productivité, il offre une réactivité

incomparable sur le temps de détection des erreurs et donc par extension sur leur résolution. Une

solution de supervision doit être entretenue avec rigueur et exhaustivité pour permettre au système

d’être réellement performant. Une supervision partielle pourrait compromettre la détection

d’erreurs potentielles dans le SI et donc provoquer des pannes critiques indésirables et non

localisées.

Dans les grandes organisations, ces outils se destinent principalement aux services d’exploitations, ils

constituent l’outil de travail principal des exploitants et des services de support. Dans les structures

IT de taille plus modeste, ils peuvent être utilisés par les administrateurs systèmes et réseaux ou par

les développeurs directement.

Il existe de nombreux outils de supervision sur le marché, offrants chacun plus ou moins de

possibilités de configuration. La solution la plus utilisée sur le marché est de loin le couple

NAGIOS/Cacti. Il existe néanmoins d’autres solutions notables telles que Icinga ou New Relic APM.

Pour plus d’informations, l’annexe 1 offre une liste détaillée des outils DevOps actuels.

1.5.4. Gestionnaires de versions

Les gestionnaires de versions, ou outils de versionning, sont des logiciels utilisés pour organiser le

code source d’un programme informatique. Ils permettent de centraliser le stockage des fichiers

sources dans un centre de dépôt, de conserver un historique des versions ou de chaque

modifications apportées à un projet. Ils permettent en autre de conserver la possibilité de revenir en

arrière facilement en cas de détection de bugs relatifs à un déploiement passé. Ces outils offrent

donc une grande réactivité et une bonne organisation. De plus, ils sont indispensables en cas de


[27]

travail collaboratif sur un projet. Chaque participant possède un compte attitré permettant

d’identifier l’apport d’un collaborateur sur le programme. Un gestionnaire de version peut également

alerter les collaborateurs lors de l’ajout de nouvelles fonctionnalités au projet en demandant une

validation manuelle pour chaque conflit détecté.

Les utilisateurs des outils de versionning sont exclusivement des développeurs. Ils constituent un de

leur outil de travail principal. Il peut également arriver qu’un administrateur accède au centre de

dépôt pour récupérer et déployer une version en production. Cependant ces accès externes sont

exceptionnels et seuls les développeurs doivent posséder un accès en écriture.

Le marché de ces outils est pour l’instant très restreint. Deux concurrents principaux se partagent le

marché : Git et Subversion. Ils possèdent des fonctionnalités similaires, cependant Git décentralise

les sources tandis que Subversion les centralise. Ils sont tous deux gratuits sans limite d’utilisation.

Pour plus d’informations, l’annexe 1 offre une liste détaillée des outils DevOps actuels.

1.5.5. Outils d’analyse de la performance

Les outils d’analyse de performances sont des logiciels permettant de mesurer de façon précise des

points de fonctionnement d’un SI. Ils sont basés sur des mesures préalablement définies par les

utilisateurs et peuvent êtres répétées si besoin. Ces outils sont le produit d’une volonté

d’amélioration de la part des DSI qui cherchent à améliorer toujours plus les temps de réponse des

applications. Elles permettent également de détecter les goulots d’étranglement des réseaux et donc

d’améliorer les performances globales du SI.

Les utilisateurs de ces outils sont essentiellement les administrateurs réseaux et systèmes. Ils sont

généralement utilisés de façon ponctuelle mais ils doivent néanmoins être mis en place lors de la

mise en production de nouveaux équipements pour conserver un historique de fonctionnement et

ainsi fournir une comparaison temporelle sur un point donné.

Le marché compte plusieurs solutions dont les plus connues sont gratuites. Iperf et Graphite sont

très souvent utilisés dans les entreprises. Pour plus d’informations, l’annexe 1 offre une liste détaillée

des outils DevOps actuels.


[28]

1.5.6. Outils de gestion des logs

Les gestionnaires de logs sont des outils destinés à collecter les logs, parfois appelé fichiers journaux

pour les langages conservateurs français, de tout ou partie d’un SI. En plus de cette collecte

centralisée, les outils sont désormais suffisamment évolués pour apporter une valeur ajoutée aux

utilisateurs par une meilleure lisibilité. Il est désormais possible de recevoir des alertes sur des logs

suspicieux. Par ailleurs des moteurs de recherche puissants et des filtres sont intégrés à ces outils

pour faciliter l’accès aux informations désirées.

Par ailleurs, la centralisation des logs offre parfois une sécurité d’accès à l’information qui serait

nullement possible autrement, par exemple en cas d’arrêt total d’un serveur ne pouvant plus

redémarrer.

Ces outils sont principalement utilisés par les administrateurs, toutes spécialités confondues, pour

comprendre les raisons d’une panne ou surveiller le bon déploiement de certaines applications

sensibles.

Il existe de nombreux outils sur le marché. Les principaux outils notables sont Logstach, Kibana, Sumo

Logic et Icinga. Pour plus d’informations, l’annexe 1 offre une liste détaillée des outils DevOps

actuels.

1.5.7. Solutions propriétaires DevOps

L’essor du mouvement DevOps a incité les principales sociétés de développement à produire des

solutions complètes intervenant sur de multiples aspects du mouvement. Ils peuvent ainsi inclure

dans leurs suites de nombreux modules de suivi de projet, d’état d’avancement, de déploiement

automatisé, de versionning et de gestion de configuration.

Ces solutions ont pour avantages d’offrir de nombreux services complémentaires. Aucune

interconnexion de produits n’est alors à mettre en œuvre. Cependant elles sont généralement très

onéreuses et inflexibles. Il faut donc adapter l’organisation de la DSI à l’outil et non l’inverse. Ces

solutions sont généralement peu adaptées aux réels besoins des organisations.


[29]

Il existe de nombreux produits de cette catégorie sur le marché. Les principaux sont Urban Code

d’IBM, OpenShift de Redhat et Microsoft Azure. Pour plus d’informations, l’annexe 1 offre une liste

détaillée des outils DevOps actuels.

1.6. Un mouvement naissant mais reconnu

1.6.1. Au cœur de l’actualité

DevOps est une culture qui gagne en popularité depuis ces dernières années et nous pouvons

observer de plus en plus de publications dans la presse informatique, de conférences et de sites

internet traitant le sujet.

Figure 14 : Evolution des recherches contenant le mot "DevOps" sur Google

Par ailleurs cette idéologie est encore récente, elle existe seulement depuis 6 ans. Elle gagne donc

progressivement en maturité grâce à une communauté active. Cela ne signifie pas qu’elle n’est pas

valable puisqu’elle a été adoptée par la plupart des grands noms du milieu, entre autres IBM,

Amazon, Google, Linkedin, Google, Netflix, Microsoft. D’après le Gartner, 25% des 2000 plus grands

groupes mondiaux s’orientent massivement vers une démarche DevOps. De plus, d’après une étude

de Vanson Bourne réalisée en fin 2014 pour le compte de CA Technologies, 49% des entreprises

matures (développant au minimum quatre applications par an) sur le marché économique des NTIC

ont adoptées l’idéologie DevOps.

De plus en plus d’outils DevOps propriétaires, libres et open sources fleurissent sur le marché. Citons

les principaux : Jekins, Chef, Puppet, Docker, Ansible, Urban Code, Windows Azure, System Center,


[30]

Visual Studio Online. Selon Gartner, le marché évoluera de 1,9 milliards de dollars en 2014 à 2,3

milliards de dollars en 2015, soit une évolution de 21%.

Enfin, DevOps est créateur d’emplois. Il n’est pas rare de trouver des offres d’emploi partiellement

ou totalement orientées vers DevOps. OVH est le principal recruteur de spécialistes DevOps en

France et propose pas moins de cents offres d’emplois spécialisés DevOps en mai 2015.

1.6.2. Exemple de pratique DevOps - Netflix

Netflix est un exemple fort d’application de l’idéologie DevOps et du « Continuous Delivery ». Riche

d’une collaboration intense entre les Dev et les Ops, Netflix est parvenu à obtenir une excellente

qualité de mise en production au travers de ses outils DevOps et de son processus de tests unique :

The Simian Army (l’armée des singes).

L’hébergement de l’infrastructure Netflix passe entièrement par les services d’Amazon AWS. AWS

(Amazon Web Services) est une collection de web services réparties dans 11 régions géographiques

mondiales destinée à fournir une large gamme de services cloud aux entreprises. Le service le plus

populaire, qui est également celui utilisé par Netflix, concerne l’Amazon Elastic Compute Cloud,

également abrégé par le terme EC2. Le service EC2 permet de fournir des serveurs virtuels évolutifs

reposants sur les technologies de virtualisation XEN. Netflix utilise donc les API d’Amazon EC2 pour

construire ses infrastructures de test et de production sur mesure pour répondre à ses besoins. La

gestion de ces infrastructure s’effectue très simplement par une interface web ou des API lui

permettant de charger n’importe quel applicatif des AMI (Amazon Machine Images) et de lancer ou

arrêter des instances de serveurs. Cette offre apporte une flexibilité particulière à Netflix puisqu’elle

repose sur un principe de location de de la puissance permettant de moduler son infrastructure par

rapport à ses besoins réels. C’est pourquoi nous parlons alors d’infrastructure « élastique ».

Pour compléter les services AWS, Netlix a créé Asgard. Asgard est un programme web permettant

d’instancier des AMI en vue de générer automatiquement des clusters EC2 par les API d’AWS.

Chaque cluster déployé par Netlfix comprend au minimum 3 machines virtuelles situées dans des

datacenters situés dans des zones géographiques différentes, lui permettant d’assurer une

redondance, une disponibilité et une répartition de ses applications à travers le monde. Ainsi, lorsque

le code est déployé sur un cluster EC2, le répartiteur de charge, communément nommé LB, redirige

un fort trafic vers ce nouvel environnement, qui est étudié intensivement durant 24h. Si cette

période d’essai est réussie, l’ancien cluster de production est automatiquement détruit au profit du


[31]

nouveau qui devient désormais le cluster maitre utilisé. Cependant si un problème est détecté durant

cette phase, le cluster est automatiquement éjecté du trafic et retourne en phase de R&D. Les

services Amazon fournissent donc à Netflix une incroyable flexibilité et un coût sur mesure qui est

très intéressant pour la société puisqu’une internalisation de cette infrastructure très changeante

provoquerait des coûts conséquents et une gestion opérationnelle particulièrement lourde et lente.

Pour automatiser ses mises en production, Netflix utilise Jenkins. Ainsi, le développeur pousse son

code sur un gestionnaire de versionning, puis les fonctions récemment programmées sont

récupérées par Jenkins qui lance la génération du build et du package applicatif. Le package est

déployé sur une nouvelle VM construite sur un squelette adopté par Netflix composé d’une

distribution Linux, de tous les logiciels Netflix (JVM comprise), de Tomcat et d’une personnalisation

du système d’exploitation comprenant les scripts de paramétrage du système, les librairies et outils

systèmes nécessaires au fonctionnement des application. Le résultat obtenu par ce processus est une

AMI fonctionnelle prête à être déployée sur un cluster de tests et soumise à la dure épreuve de la

Monkey Army.

The Simian Army est un programme développé par Netflix qui agit sur les plateformes de tests de la

société. Son seul objectif est de semer le chaos en simulant tous les problèmes que pourrait

rencontrer une application en production. Cette pratique surprenante oblige les équipes de

développement à réfléchir de manière intensive à la haute disponibilité de l’application. Pour une

société de services de vidéo à la demande, la rupture de service n’est bien sûr pas envisageable car

elle dégraderait l’image de la société aux yeux de ses clients.

Netflix a pour cela mis l’accent sur sa politique de « fail early, fail often » pour construire son

infrastructure. Ainsi, d’après Netflix, il n’est qu’une question de temps pour qu’une application

rencontre un problème une fois mise en production. Il faut donc précipiter les incidents pour savoir

comment les corriger sur un plan applicatif avant qu’ils s’opèrent en production. Cela évite la

précipitation et donc les corrections temporaires hasardeuses qui ne solutionnent en rien un

problème au sens ITIL du terme. Ce système a été en partie conçu par Jeremy Edberg, une référence

dans le domaine de création d’infrastructures sur mesure pour les géants du cloud.

Voici comment se traduit le concept de Simian Army :


[32]

Figure 15 : Concept de la Simian Army présentée par Netflix


[33]

Composition de la Simian Army (chaque singe représente un script qui s’exécute à un moment

aléatoire et/ou répété) :

- Le Chaos Monkey désactive aléatoirement une instance de l’infrastructure pour s’assurer de

la haute disponibilité du programme ;

- Le Latency Monkey ajoute une forte latence sur un service REST en vue de simuler une forte

charge d’utilisation ;

- Le Conformity Monkey cherche les fonctions qui ne correspondent pas aux bonnes pratiques

imposées par la société et les supprime automatiquement ;

- Le Doctor Monkey analyse la ligne de vie des serveurs monitorés et les exclus du cluster en

cas de signe de défaillance ;

- Le Janitor Monkey recherche les instances qui gaspillent des ressources ou qui les sous

utilisent pour les supprimer ;

- Le Security Monkey fonctionne en binôme avec le Conformity Monkey pour contrôler les

points de sécurité et renouveler les certificats ;

- Le 10-18 Monkey détecte les problèmes de répartition géographique de la charge ;

- Le Chaos Gorilla ressemble au Chaos Monkey, toutefois au lieu d’éteindre une seule machine

il coupe entièrement un datacenter virtuel.

Suite à ce cas d’étude, nous pouvons constater que Netflix respecte l’idéologie DevOps et les

principes du continuous delivery :

- L’encouragement du changement et ne pas avoir peur de l’échec : par les mises en

production qui redirigent une partie du trafic durant 24h sur un cluster EC2 récemment

déployé en vue de desceller les éventuels problèmes.

- La collaboration entre les Dev et les Ops : en vue de posséder une infrastructure toujours

plus puissante et opérationnelle sans amoindrir la qualité

- La responsabilisation des acteurs : par la totale maitrise des processus de mise en production

par les équipes de développement.

- L’automatisation des mises en production : qui respectent les principes inculqués par le

Continuous Delivery

- L’automatisation des tests : grâce à la Simian Army et au monitoring intensif de chaque

fonctionnalités dans le but de s’assurer de la qualité et de la haute disponibilité de

l’application.

- La culture de l’innovation : par une incitation et une facilité de mise en production qui

permet aux développeurs d’apporter des modifications à la production sans aucune limite.


[34]

Grâce à ce système, Netflix a su transposer les concepts Agiles, DevOps et du Continuous Delivery à

son organisation interne. Aujourd’hui la société parvient à procéder à une moyenne de 24 mises en

production quotidiennes.

1.6.3. Exemple de pratique DevOps - OVH

Le DevOps est une idéologie qui s’est rapidement démocratisée au sein du plus grand hébergeur

français, OVH. Contrairement à Netflix, s’approche se concentre sur l’idéologie, plus que sur la mise

en pratique de la culture DevOps. Nous pouvons facilement imaginer que cette tendance est liée à

l’activité de l’entreprise. Tandis que Netflix cherche à optimiser ses mises en production, OVH

cherche à stabiliser l’évolution exponentielle de son infrastructure (plus de 200 000 serveurs en

2015) sans amoindrir l’intégration de ses nouveaux services développés par la branche R&D du

groupe.

Concrètement, pour OVH, il importe que ses développeurs se soucient des ressources nécessaires au

bon fonctionnement du programme et que les administrateurs systèmes comprennent les enjeux et

les problématiques des développeurs. Cette approche est donc beaucoup plus proche d’une

philosophie DevOps pure et tend vers l’uniformisation de la DSI sans pour autant perdre de vue la

spécialisation des profils, clé de la productivité.

Ainsi pour pallier à cette problématique de séparation des équipes, DevOps ajoute un nouveau profil

de poste à son portefeuille de compétences : les DevOps. Pour OVH, les ingénieurs DevOps sont des

profils informatiques dotés d’une double compétence en développement et administration de

systèmes. Cette double compétence leur permet de gagner en réactiver sur les projets qu’ils leur

sont confiés. De plus ils possèdent une vision globale sur les technologies utilisées dans la société et

cette double compétence se ressent fortement sur un individu amené à gérer plusieurs milliers de

machines.

OVH a ressenti le besoin d’instaurer la culture DevOps suite à un constat d’un manque de réactivité

et d’une trop forte rigidité dans l’exécution des procédures. Cette faiblesse s’est révélée être très

impactante pour la société, notamment dans le cadre de mise en œuvre de projets critiques. OVH a

donc rectifié sa trajectoire en formant ses collaborateurs à l’Agilité, au DevOps et au développement

continu, mais aussi en ouvrant massivement ses portes aux spécialistes DevOps, chargés de répandre

la culture et améliorer les processus de mises en production au sein de la firme.


[35]

Cette adaptation à la culture DevOps a engendrée une amélioration du cycle de mise en production

au sein d’un projet :

- Phase n°1 : Le développeur a pour objectif de développer deux ou trois fonctions de

l’application en un temps restreint de deux semaines ;

- Phase n°2 : A l’issue de cette période l’application est livrée aux bêta-testeurs ;

- Phase n°3 : Le développeur reçoit le feedback des tests réalisés et corrige les éventuels bugs

applicatifs rencontrés.

Le cycle se renouvelle jusqu’à l’obtention d’une application parfaitement testée et fonctionnelle. La

mise en production de l’application peut ensuite être déployée dans l’environnement de production.

Par ailleurs, OVH tente de rendre ses technologies facilement accessibles aux nouveaux

collaborateurs. Pour cela, la société évite dans la mesure du possible de se créer ses propres outils de

développements ou d’administration pour se concentrer sur les outils déjà présents sur le marché et

très largement diffusés. Ce point évite de former les collaborateurs sur de nombreux outils lors de

leur intégration et permet de se concentrer sur le fond du métier et non sa façon de l’exécuter.

« Nous souhaitons que nos collaborateurs soient pragmatiques, qu’ils se remettent en question. »

Edouard VANBELLE, responsable de l’hébergement mutualisé chez OVH.com


[36]

2. Les rouages des DSI et leurs complexités

2.1. Qualification et structure d’une DSI

2.1.1. Le rôle d’une DSI

La DSI, Direction des Systèmes d’Information, est l’entité d’une organisation qui est en charge de la

gestion informatique. Au sens large, elle gère tout ce qui se rattache de près ou de loin au domaine

des NTIC.

Une DSI possède généralement trois pôles de compétences :

- Les études (le métier) : en charge de la conception des SI.

- L’expertise (les développeurs) : capitalise et met en œuvre le savoir-faire.

- La production (les opérationnels) : responsable de la gestion et de l’évolution de

l’infrastructure.

Elle peut également se découper par les fonctions détaillées suivantes :

- Le pilotage de la DSI : Aligne le SI sur les exigences de la direction et définit les stratégies à

adopter au sein de la DSI.

- L’assistance utilisateurs : Service au contact direct des utilisateurs internes et qui assure le

support technologique.

- Les fonctions transverses : Garantissent la performance et la qualité du SI par le pilotage de

projets et la rédaction de normes qualitatives.

- La relation fournisseurs : intermédiaire entre la DSI et les fournisseurs informatiques.

- Les études : Conçoivent le SI et axe son évolution par l’initiation et le suivi de projets.

- La production : Ensemble des équipes en charge de l’exploitation et de l’évolution de

l’infrastructure.

- L’expertise : Ensemble d’experts qui créent des programmes et apportent leurs savoir-faire.

- Les fonctions support : Fonctions transverses veillant à la mise en place des processus et au

respect des référentiels de la DSI.

2.1.2. La structure organisationnelle

Les DSI sont des entités qui ont fait leur apparition relativement récemment dans les organisations et

il est fréquent d’observer des différences sur leur structure organisationnelle. En effet, selon leur


[37]

degré d’évolution, leur taille et le métier de l’entreprise elles peuvent prendre des formes

différentes. Toutefois, de par la composition des métiers, le squelette organisationnel reste commun

à la quasi-totalité des organisations en mode projets.

Les petites structures possèdent évidemment une organisation plus simple et donc plus encline au

changement. Dans cette structure de petite taille, l’échelonnage est beaucoup moins présent et les

collaborateurs sont généralement polyvalents.

Figure 16 : Représentation d'une organisation structurelle d'une DSI de taille petite ou moyenne

Dans ce type de structure la polyvalence est la clé de la réussite. Le faible nombre de ressources

oblige les collaborateurs à changer de fonction selon les circonstances. Dans toute structure il est

impératif pour la pérennité de l’entreprise d’assurer la redondance des compétences pour pallier aux

éventuelles absences d’un collaborateur. Toutefois, dans les petites structures cette redondance ne

peut pas toujours se réaliser au sein de la même cellule. Les développeurs et les administrateurs

peuvent donc assurer une fonction de support parallèlement à leur activité et partager leurs

compétences entre eux. Il n’est pas obligatoire d’être aussi performant mais il faut au minimum

assurer le maintien de l’activité de façon transparente face aux clients ou aux utilisateurs.

A contrario, une DSI de grande taille aura facilement tendance à se fragmenter en de multiples

équipes, également appelées cellules de travail. Cette fragmentation traduit un besoin ressenti de

séparation des compétences afin de correspondre aux modèles d’organisation pyramidaux actuels

que nous rencontrons aujourd’hui.

DSI

Pôle développement

Pôle administration

Pôle support

Assistante de direction


[38]

Figure 17 : Représentation d'une organisation complexe de DSI d'une dimension humaine importante

Au travers des deux schémas présentés précédemment, nous pouvons constater que plus le nombre

de collaborateurs augmente dans la DSI plus elle se fragmente. Cette fragmentation est à l’origine

des silos que nous connaissons aujourd’hui dans les grandes sociétés. Elle provoque une réelle

étanchéité des cellules face aux besoins des autres équipes.

DSI

Cellules transerves

Urbanisme

Architecture

Méthodes

Sécurité

Production

Exploitation

Administration réseau

Administration sytèmes

Administration postes

Adminsitration ToIP

Administration virtualisation

Administration stockage

Administration bases de données

Support

Centre d'appels

Assistance interne N1



Assistance fonctionnelle

Centre de maintenance

Administration

Achats IT

Facturation

Communication

RH

Bureaux d'Etudes

Périmètre X

Périmètre Y

Périmètre Z

Intranet

Multimédia


[39]

2.1.3. Evaluer la performance de l’équipe et de la DSI

Avant d’imposer des changements il est nécessaire de s’interroger sur la maturité de l’équipe ou du

service. Il faut alors déterminer à quel stade d’évolution en est la cellule en prenant en compte d’un

point de vue objectif les forces et les faiblesses de cette dernière. Il sera ainsi possible de la

positionner sur un degré plus ou moins avancé en termes de maturité et de performance. Cette

analyse se pratique généralement sur une cellule de petite taille afin d’être réellement pertinente,

mais il est néanmoins possible de l’appliquer à la DSI toute entière pour disposer d’un point de vue

global.

Nous disposons donc d’un panel de sept catégories de classification d’équipe présentées par ordre

croissant de performance :

- Stade n°1 – Orientation : Lors de cette étape les collaborateurs doivent comprendre

pourquoi ils sont dans l’équipe et quelle est leur rôle dans la structure.

- Stade n°2 – Construire la confiance : Lors de cette étape les collaborateurs doivent

apprendre à se faire confiance. Ils doivent pouvoir être solidaires et compter les uns sur les

autres.

- Stade n°3 – Clarifier les objectifs : A ce stade, des mesures sont mises en place sur les

atteintes des objectifs tactiques.

- Stade n°4 – Engagement : Lors de cette phase les membres de la cellule doivent être engagés

dans le processus de réussite de l’équipe et prendre des initiatives. Les rôles de chacun sont

clairement définit.

- Stade n°5 – Implémentation : A ce niveau de performance, la cellule doit maitriser des

processus courants et être organisée dans l’exécution des tâches confiées.

- Stade n°6 – Haute performance : Lors de cette étape les interactions intra-équipe sont

spontanées, des synergies commencent à se former et les résultats sont surpassés.

- Stade n°7 – Renouvellement : Ce dernier stade de performance de l’équipe entraine

généralement des félicitations de la part de la hiérarchie. L’équipe possède une parfaite

maitrise du changement et est fortement résistante à toute les pressions subies.


[40]

Figure 18 : Représentation graphique des différents stades de maturité d'une cellule de travail

Appliquer cette analyse permettra aux responsables de la conduite du changement d’adopter les

bons moyens de mise en œuvre. S’il serait aisé d’opérer des changements radicaux sur une équipe à

un niveau de « haute performance », il serait inapproprié de perturber les méthodes de travail sur

une cellule à un stade de « construire la confiance », cela créerait une pression néfaste sur l’équipe

pouvant entrainer une démotivation des collaborateurs. C’est exactement ce type de situation qui

peut perturber l’intégration de la culture DevOps en entreprise. Il sera ainsi préférable de modérer

les changements au profit d’une intégration plus lente mais en douceur.

2.1.4. L’évolution de la DSI

La DSI était autrefois perçue comme un centre de coûts importants mais nécessaire. L’objectif était

alors de disposer d’une entité proportionnée et parfois sous dimensionnée par rapport aux réels

besoins afin de minimiser les pertes financières. Toutefois la tendance est en cours d’inversement

puisque la DSI prend un rôle déterminant pour l’entreprise. Une DSI performante apporte donc une

plus-value conséquente pour l’ensemble de l’entreprise. En effet, une DSI compétente permettra

d’augmenter la productivité du travail pour chaque service de l’entreprise au travers de formations,

de solutions adaptées, parfois même sur mesure, mais également en répondant rapidement à tous

les besoins internes. Grâce à cela, les collaborateurs pourront se concentrer pleinement sur le cœur

•Maintient à ce stade : Confusion, incertitude, peur

•Objectifs pour passer à l'étape suivante : Finalité, identification de l'équipe, appartenance 1. Orientation

•Maintient à ce stade : Précaution, méfiance, duplicité

•Objectifs pour passer à l'étape suivante : Respect, sincérité, confiance

2. Construire la confiance

•Maintient à ce stade : Apathie, scepticisme, concurrence

•Objectifs pour passer à l'étape suivante : Hypothèse explicites, objectifs clairs, vision partagée

3. Clarifier les objectifs

•Maintient à ce stade : Dépendance, résistance au changement

•Objectifs pour passer à l'étape suivante : Ressources affectées, rôles définis, décisions prises 4. Engagement

•Maintient à ce stade : Conflits, confusion, délais dépassés

•Objectifs pour passer à l'étape suivante : Processus clairs, cohérence, exécution organisée 5. Implémentation

•Maintient à ce stade : Surcharge, incohérence

•Objectifs pour passer à l'étape suivante : Interactions spontanées, synergies, résultats surpassés

6. Haute performance

•Maintient à ce stade : Ennui, épuisement

•Objectifs de confirmation: Reconnaissance et félicitations, endurance, maitrise du changement 7. Renouvellement


[41]

de métier et percevoir l’usage de l’informatique comme une aide précieuse et non comme un outil

peu facile à utiliser ou défaillant.

C’est grâce à cette nouvelle dimension stratégique attribuée à la DSI que la plupart des sociétés

convient désormais le directeur des systèmes d’information aux comités de direction. Ce dernier a

ainsi l’occasion de partager avec ses collaborateurs la vision stratégique qu’il entreprend de mettre

en œuvre sur le SI mais aussi d’appuyer ou non les autres membres du comité de direction sur les

solutions qui sont techniquement envisageables pour mener à bien leurs ambitions.

2.2. Les enjeux de performance du SI

2.2.1. Les enjeux économiques

Du fait de la globalisation générale des activités des entreprises entrainée par la mondialisation du

commerce par les nouvelles technologies, les sociétés se confrontent à des marchés concurrentiels

devenus désormais très prononcés. La collaboration des métiers de l’entreprise avec la DSI lie donc la

compétitivité de l’entreprise à la performance du SI. Selon le secteur d’activité de l’entreprise, la

dimension stratégique du SI peut donc prendre une importance capitale. Les dirigeants souhaitent

alors retirer un avantage concurrentiel par l’avancement technologique de la société. Cette

affirmation devient encore plus importante dans le cadre d’une activité numérique. Il est important

de retenir que si une DSI entraine des dépenses importantes, elle est indispensable à la réussite

économique de la société.

Concrètement, le SI agit directement sur la puissance commerciale de la société. En effet, un CRM en

adéquation aux besoins des commerciaux terrains permettra d’accroitre la qualité de la relation

cliente, de réaliser un suivi des ventes, de diffuser à l’ensemble des utilisateurs des informations

précieuses sur les tarifications et les nouveaux produits catalogues. De plus, les commerciaux

pourront facilement devenir autonomes sur le terrain, grâces aux solutions portatives. Cette

autonomie leur permettra de disposer de l’intégralité de leurs outils de travail sur tous les supports

nomades actuels et ils pourront ainsi assurer leur fonction partout dans le monde. Enfin, il est

également possible de mettre en œuvre des sites marchands afin d’élargir la clientèle de

l’organisation et toucher de nouveaux marchés à l’international.

Par ailleurs le SI fournira les outils de marketing permettant de valoriser l’image de marque afin de

mettre en avant la société par rapport à ses concurrents. Une société visible sur internet grâce à des


[42]

sites vitrines, des publications, un community management et un bon référencement sera un

avantage concurrentiel incontestable.

De plus, dans sa globalité, un SI performant permettra d’accroitre la productivité des collaborateurs

utilisant un poste de travail dans le cadre de leurs fonctions. Un poste de travail correctement

configuré par rapport au profil de poste du collaborateur contribuera à son épanouissement et à la

rapidité d’exécution des tâches. Un support réactif rassurera le collaborateur en cas de doute et des

formations dispensées permettront de lui faire gagner en maitrise de son outil et donc en rapidité de

production.

Enfin, la performance du SI impactera les relations entre les collaborateurs. L’intégration d’outils de

communication efficaces sera un atout pour fluidifier les échanges dans l’entreprise. Les messageries

électroniques et instantanées mais aussi les services de ToIP multiplateformes permettront aux

collaborateurs de communiquer plus efficacement et plus rapidement à chaque moment de la

journée sans contrainte. La rapidité d’échanges d’informations impacte alors positivement la

collaboration entre les utilisateurs, qui pourront se recentrer sur leur cœur d’activité.

2.2.2. Une exigence qualitative

Depuis la fin du XXe siècle, les acteurs du monde informatique ne cessent de s’interroger sur les

façons d’améliorer la qualité des SI au travers de nouvelles méthodes, idéologies et cultures. Un

sentiment partagé de manque de performance est ressenti et le besoin de le combler apparait.

Aujourd’hui il ne s’agit plus d’assurer l’accès des postes de travail aux collaborateurs de

l’organisation mais de construire un SI performant et évolutif sur le long terme. Dans la construction

et l’évolution du SI, les mauvaises décisions peuvent engendrer des coûts financiers conséquents

pour l’organisation. En effet, si le SI repose sur des fondations inadaptées peu évolutives et que

d’autres briques reposent sur cette structure, le changement inévitable de cette composante pourra

se révéler difficile voire impossible à conduire. Ainsi, les dirigeants se retrouveront dans une position

délicate à devoir choisir entre conserver l’existant devenu non productif et un changement risqué

entrainant des pertes colossales pour l’organisation. C’est pourquoi, le SI doit toujours être conçu de

façon à pouvoir tolérer les futures innovations. C’est pourquoi les manageurs imposent désormais de

fortes exigences qualitatives sur l’intégralité des projets menés. En résumé la DSI se doit d’assister au

mieux l’entreprise dans son activité et ne surtout pas la pénaliser inutilement, car les coûts liés au SI

prennent une part de plus en plus importante du chiffre d’affaire réalisé.


[43]

2.3. Analyse des relations sociales

2.3.1. La position de l’homme dans la structure

La taille d’une structure informatique influence fortement la rapidité d’intégration d’une culture telle

que DevOps. Plus la structure devient importante, moins le collaborateur se sent concerné par la

réussite collective et plus il devient difficile d’aborder les changements.

Cette logique s’explique notamment par la vision dont dispose le collaborateur sur l’entreprise. Dans

le cadre d’une PME, le collaborateur est en relation avec la plupart des acteurs de l’entreprise, il

côtoie régulièrement la direction et peu de barrières séparent les dirigeants des exécutants. Le

collaborateur est donc inévitablement soumis à l’effet de groupe et se sent impliqué dans la réussite

des projets. Il dispose ainsi d’une vision globale lui donnant le sentiment de faire partie intégrante

d’un groupe d’individus et il est très attaché à la réussite de ce dernier. Le collaborateur a le

sentiment de pouvoir faire avancer la structure par sa force de travail.

Cependant dans le contexte d’une grande organisation la philosophie des collaborateurs est très

différente. Ils sont un sentiment d’appartenance à une équipe et à un service mais étant donné qu’ils

ne possèdent pas de vision globale sur l’entreprise, ils se recentrent sur des objectifs plus proches de

leur réalité à un niveau restreint d’équipe. Ainsi, plus la division structurelle de l’organisation est

prononcée, plus le collaborateur se sentira petit au sein de la structure. Il minimisera donc

l’importance de son travail en pensant que la réussite du groupe lui est étrangère. Cette affirmation

n’est pas fondamentalement fausse car lorsqu’une DSI dispose de plusieurs centaines de

collaborateurs la réussite globale se répartie sur les épaules de chacun des acteurs et la pression, et

donc par extension l’implication du collaborateur, devient moins forte. De plus, la composition

d’équipes spécialisées répartie les fautes et les succès sur toute l’unité. Le collaborateur obtient donc

moins de reconnaissance de la part de sa hiérarchie car les mérites sont attribués à l’équipe entière.

A l’inverse, en cas d’erreur commise, le collaborateur partagera la faute avec le reste son équipe et

se sentira moins responsable de l’échec.

Toutefois, dans les grandes organisations, il est difficile de progresser hiérarchiquement tant la

concurrence est accrue. Pour atteindre ses ambitions un collaborateur devra attirer le regard de ses

manageurs par des faits exceptionnels ou en se mettant en avant par rapport aux autres

collaborateurs. Cette situation peut générer des conflits internes provoqués par un sentiment de

concurrence exacerbée. Ainsi, au lieu d’agir pour l’intérêt commun, les collaborateurs auront

facilement tendance à dériver vers une situation conflictuelle dans laquelle chacun essaye à tout prix


[44]

de protéger ses intérêts personnels. Cette situation est évidemment gérable lorsque les cas sont

isolés mais elle peut cependant tendre à se généraliser rapidement car les nouveaux collaborateurs

auront tendance à prendre l’empreinte des plus anciens. Ancrés dans cette négativité, les membres

d’une équipe réduiront ensuite au maximum toute prise de risque. Ce point est également très

néfaste pour une société puisque seule la prise de risque permet à l’entreprise d’innover et de se

démarquer. Le collaborateur s’enferme donc dans une zone de confort, à l’abri de tout danger, pour

réaliser ses tâches de façon précises certes, mais sans valeur ajoutée.

Figure 19 : La position de l'homme dans une structure de grande taille

Ces points négatifs sont des freins très importants pour la mise en place d’une nouvelle culture dans

l’entreprise car ils vont à l’encontre des grands principes DevOps (la confiance, l’encouragement de

l’innovation, la collaboration, l’ouverture d’esprit, etc.).

2.3.2. Les canaux de communication

Depuis le début du XXIe siècle, l’apparition des nouvelles technologies a apporté de nombreux

changement sur les moyens de communications internes. Si la multiplication des outils de

Groupe/Entreprise

Entité/filliale

Département

Service

Equipe

Acteur

IT


[45]

communication et la facilitation des accès à ces derniers ont fortement contribué à l’amélioration de

la rapidité des échanges, les relations ont perdu en authenticité. Désormais les collaborateurs

privilégient la vitesse de la communication à la qualité et génère de l’étanchéité entre les équipes.

On appelle ce phénomène par des équipes en « silos ».

Ainsi, chaque moyen d’échange possède des avantages et des inconvénients que chaque

collaborateur devrait maitriser.

Canaux de communication internes

Avantages

Inconvénients

Téléphone Rapidité d’échange

Bonne réactivité

Possibilité d’échange en temps réel

Aucune trace des échanges

Messagerie électronique (eMails)

Conserve une trace datée de chaque échange

Permet de diffuser une information rapidement à plusieurs destinataires

Permet de construire un fil d’échange

Il est difficile de s’assurer que le destinataire a bien reçu l’information

La surutilisation des mails entraine une pollution des boites de réception

Peut rapidement devenir chronophage

Messagerie instantanée

Pratique pour une prise d’information simple

Permet d’échanger rapidement et de façon non formel avec un collaborateur

En principe facile d’utilisation

Ne conserve pas de trace

Devient très chronophage en cas d’échange prolongé

Face à face Permet de créer un lien relationnel entre les participants

Echange directe et rapide

Coupe le destinataire dans son activité

Courrier postal Permet de joindre des documents physiques

Permet de demander un accusé de réception

Extrêmement lent

Couteux

Devenu obsolète face aux messageries électroniques

Réunion Forte interaction entre les participants

Possibilité d’échanges de groupe à longue durée

Ecoute active de tous les participants

Très chronophage

Met fin à la période de travail du collaborateur brutalement, selon des horaires fixés à l’avance

Génère de fortes contraintes horaires

Nécessite une gestion du temps rigoureuse


[46]

Panneaux d’affichage

Diffuse l’information très largement sur une zone géographique précise

Demande un entretien régulier

Il est impossible de s’assurer que le destinataire a bien reçu l’information

Seules des informations secondaires ou pratiques peuvent être affichées

Se limite à une zone géographique seulement

Figure 20 : Comparatif des canaux de communication internes

On remarque une tendance à la surutilisation des messageries électroniques et instantanées dans les

organisations au détriment de la communication orale. Cela s’explique pour des raisons de

productivité. Toutefois ce changement diminue la solidarité entre les équipes et il n’est pas rare de

se retrouver dans un échange de mails qui s’est transformé en un véritable règlement de comptes où

chaque échange inclus de plus en plus de participants dans la boucle de communication. Chaque

participant essaye alors de justifier ses propos aux yeux de tous en perdant de vue l’objectif initial de

la communication ou sans prendre en compte les intérêts collectifs. Ainsi, par exemple, certains

collaborateurs rejettent une faute sur autrui, en se justifiant par de long propos dans le but de se

protéger de toute accusation. On est ici dans une démarche de blâme négative non constructive qui

entraine une dégénération des relations sociales. Dans ce genre de situation, il est préférable de

mettre son égo de côté et de s’entretenir collectivement pour trouver la meilleure solution

corrective. C’est pourquoi le choix des canaux de communication est devenu un moyen de se

protéger et non une façon collective d’avancer. Les motivations sont donc régulièrement mal

fondées dans les grandes organisations.

2.3.3. Les différences de perception entre les équipes dans les DSI

Dans les DSI et plus largement dans le monde informatique, les développeurs s’opposent aux Ops par

leur conception de l’informatique. Même si cette vision reste très manichéenne elle reflète tout de

même le courant actuel et met en avant un centre d’opposition entre les deux côtés. Effectivement,

la nature d’activité de chaque partie influence le travail de l’autre en le rendant difficile à exercer.

Pour mieux comprendre l’origine de cette opposition il est nécessaire de s’interroger sur les

motivations des deux bords. Les développeurs ont pour objectif de créer des applications rapidement

et fréquemment. Pour mener à bien leur mission ils doivent prendre des risques, être rapides et

apporter de nouvelles fonctionnalités le plus fréquemment possible. A l’inverse, les Ops ont pour


[47]

mission d’assurer le bon fonctionnement de l’infrastructure. Pour remplir leur mission ils doivent

stabiliser l’état actuel de la production, anticiper les futurs modifications à venir et rendre

l’infrastructure toujours plus sûr.

Figure 21 : Les objectifs opposables des Dev et des Ops

Cette opposition fondamentale sur la nature de leurs objectifs est alors logiquement une source de

conflit pouvant sembler insurmontable pour chacune des parties.

Le scénario est alors souvent identique :

1. Le développeur souhaite publier une nouvelle fonctionnalité en production et formule sa

demande aux Ops.

2. L’administrateur système oppose une résistance en demandant au développeur de lui démontrer

le bon fonctionnement de son code, de lui fournir une procédure d’intégration précise ainsi

qu’une documentation à jour et un jeu de tests à réaliser.

3. Le développeur a le sentiment de perdre du temps avec des futilités. Il a ainsi tendance à mettre

la pression sur les Ops pour accélérer l’opération.

4. Les opérationnels ne veulent pas travailler dans l’urgence par nécessité de qualité et se sent

agressé par le développeur qui selon eux ne souhaite pas respecter les procédures mises en place.

5. La mise en production s’effectue dans une ambiance impropre à la collaboration et la

communication est minimum.

6. En cas d’erreur lors de la mise en production chaque partie tentera de reporter la faute sur

l’autre.

Dev • Changements

• Rapidité

• Risques

Ops • Stabilité

• Prévisibilité

• Sureté


[48]

Cet exemple est caricatural mais malheureusement bien proche de la réalité. Il est évident que les

Dev et les Ops se concentrent sur leur objectifs d’équipes et perdent de vue l’intérêt général ainsi

que celui des utilisateurs. Aucun service n’est à blâmer car les objectifs sont définis par les

manageurs qui souhaitent eux aussi remplir leurs objectifs. Afin d’éviter ce genre de friction les DSI

mettent en place des processus de mise en production. Aux premiers abords l’idée semble être juste

et adaptée mais dans la pratique les opérations deviennent très lourdes, complexes et lentes. De plus

les deux parties auront tendance à s’enfermer dans le strict respect des procédures et cette

bureaucratie exagérée deviendra néfaste à la coopération. Quand les procédures deviennent

omniprésentes et trop rigides, les collaborateurs ont un risque élevé de s’éloigner du bon sens, de

l’évidence. Ainsi, une opération simple peut rapidement devenir compliquée et chronophage pour

les deux parties. Les procédures auront l’effet inverse de celui recherché initialement.

Par ailleurs, les deux parties sont par nécessité obligées de collaborer ensemble, elles sont

complémentaires. Elles n’ont d’autres choix que de devoir coopérer pour que chacune puisse remplir

ses objectifs. Cependant, d’un point de vue humain, il est difficile de faire des concessions.

2.3.4. Les pressions managériales

Les décisionnaires jouent un rôle important dans les conflits entre les Dev et les Ops. Au travers de

leur politique de management ils provoquent inconsciemment des conflits interservices. Ces conflits

sont directement issus de la pression subie par les collaborateurs de la part des manageurs qui

imposent à leurs équipes de réaliser en temps voulu les objectifs.

Ainsi, les développeurs peuvent obtenir des bonus sur le respect des délais de développement, le

nombre de fonctionnalités et l’innovation proposée dans les projets

Quant aux opérationnels, ils peuvent obtenir une prime sur la disponibilité de l’infrastructure ou des

applications et sur objectifs (par exemple atteindre 99,9% de disponibilité ou la réduire le nombre

d’erreurs apparaissant dans les outils de supervision).

Ces bonus étant propres et opposés pour chaque partie, chacun tentera d’imposer sa façon de

procéder. Les objectifs sont donc bien trop personnels et devrait être plus partagés afin d’œuvrer

pour une collaboration plus saine.

Par ailleurs, les manageurs perçoivent une forte pression issue originellement du client final. Au lieu

d’amortir la pression et de la transformer en objectifs atteignables à courts termes, les dirigeants ont


[49]

tendance à transférer la pression sur leur équipes. Et à leur tour les développeurs transmettront la

pression aux opérationnels pour accélérer les mises en production.

Figure 22 : La chaine de transmission de la pression entre les acteurs d'un projet IT

Au final, toute la pression sera amortie en fin de cycle de déploiement sur les opérationnels, ce qui

relancera à nouveau la situation conflictuelle. Les opérationnels ne peuvent subir toute la pression, il

est impératif de la répartir entre tous les acteurs. De plus, une pression modérée infligée sur tous les

acteurs d’un projet sera bénéfique puisqu’elle sera une source de motivation et de dépassement de

soi. En revanche, une pression trop forte génèrera un stresse beaucoup trop intense et le

collaborateur pensera que les objectifs sont inatteignables, il sera donc démotivé.

2.4. Théories et concepts de management appliqués aux organisations IT

2.4.1. La hiérarchie des besoins selon Maslow

En 1943, Abraham Maslow a publié un article « A Theory of Human Motivation » dans lequel apparait

pour la première fois la pyramide des besoins. Cette publication a donné naissance à la théorie de

Maslow, qui est encore utilisé dans le monde professionnel et de la psychanalyse aujourd’hui. La

pyramide de Maslow hiérarchise les besoins de chaque être humain sous forme d’étape à accomplir.

Maslow part ainsi du principe qu’un être humain commence par assouvir ses besoins primaires avant

de vouloir réaliser des besoins moins nécessaires à sa survie mais concentrés sur son

épanouissement personnel. Ces besoins sont regroupés sous cinq stades, la base de la pyramide

représentant donc les premiers besoins qu’un Homme tentera de réaliser. Maslow part du principe

que l’être humain cherchera toujours à s’améliorer et donc à gravir les échelons de cette pyramide

jusqu’à arriver au sommet.

Administrateur systèmes

Développeur Lead

développeur MOE Client

Transfert de la préssion


[50]

Figure 23 : Pyramide des besoins selon Abraham Maslow

Détail des différents niveaux de la pyramide de Maslow :

- Besoin d’accomplissement de soi : Selon Maslow ce stade représente le sommet des

aspirations humaines. L’individu cherche à sortir d’une condition matérielle pour atteindre

l’épanouissement total. Ce stade passe par l’approfondissement de la culture, le

développement personnel, la méditation, l’autonomie, la prise de décision et la formation de

son propre développement.

- Besoin d’estime : L’individu cherche à être reconnu en tant qu’entité propre parmi les

groupes dans lesquels il évolue. Il cherche à sortir du lot, devenir autonome dans ses

fonctions, faire un travail utile, définir ses objectifs professionnels, entendre des

compliments et exprimer ses compétences.

- Besoins d’appartenance et d’amour : A ce stade l’individu rentre dans une dimension

sociale, il ressent le besoin d’être accepté dans des groupes (famille, amis, travail,

association, etc.). L’individu recherche de l’affection de la part de ses semblables.

- Besoin de sécurité : L’individu souhaite évoluer dans un environnement stable et prévisible,

sans anxiété ni crise. L’individu souhaite se protéger contre les dangers qui l’entourent.

- Besoins physiologiques : Ce besoin est directement lié à la survie de l’individu. Ce sont des

besoins concrets : faim, soif, sexualité, respiration, sommeil, etc.

Besoin d'accomplisse-

ment de soi

Besoin d'estime

Besoins d'appartenance et d'amour

Besoin de sécurité

Besoins physiologiques


[51]

Toutefois, d’après Maslow, il convient de nuancer l’idée préconçue par laquelle un individu doit

réaliser à 100% ses besoins avant de chercher à réaliser des besoins supérieurs. Il faut alors concevoir

la hiérarchie des besoins sous une forme plus dynamique où un stade intermédiaire de la pyramide

peut être ressenti comme un besoin anticipé.

Figure 24 : Représentation dynamique de la hiérarchie des besoins selon Maslow

Une personne capable de travailler dans une structure moderne aura au minimum achevé les trois

premières étapes de la pyramide de Maslow. Le collaborateur cherchera donc à découvrir son vrai

potentiel et à l’exploiter au maximum afin d’atteindre l’épanouissement personnel et professionnel.

2.4.2. Les X et les Y

La théorie X et Y est une hypothèse de management utilisée en gestion de ressources humaines et en

comportement de l’organisation. Publiée en 1960 par Douglas McGregor dans son ouvrage « The

Human Side of Enterprise », elle oppose la théorie des X à celle des Y. La première théorie expose un

point de vue selon lequel l’homme n’aime pas travailler. La deuxième suppose le fait inverse. Ainsi en

contrastant ces deux théories il est possible d’observer de façon objective les comportements

humains au sein des organisations.

McGregor exprime par la théorie des X le fait que l’homme éprouve une aversion innée pour le

travail et met tout en œuvre pour l’éviter ou le contourner. Ainsi, l’individu moyen préfère être dirigé

Besoins physiologiques

Besoin de sécurité

Besoin d’appartenance

Besoin d’estime

Besoin d’accomplissement de soi


[52]

et contrôlé par sa chaine hiérarchique. Plusieurs points de suppositions sont donc mis en avant dans

cette théorie :

- L’homme n’aime pas le travail ;

- Les collaborateurs doivent être contrôlés et dans certains cas extrêmes menacés pour qu’ils

puissent arriver à travailler en conséquence ;

- Les travailleurs ne fournissent un effort supplémentaire que sous la contrainte ;

- L’homme préfère être dirigé ;

- Le collaborateur cherche toujours à fuir ses responsabilités ;

- L’individu recherche avant tout la sécurité ;

- L’homme n’utilise son intelligence seulement pour exploiter les failles des règlements

internes aux organisations.

Cette théorie génère ainsi un cercle vicieux dans lequel l’attitude des collaborateurs incite les

dirigeants à adopter des stratégies de contrôle toujours plus strictes. L’attitude des dirigeants

entraine quant à elle de plus en plus de passivité chez le collaborateur.

Figure 25 : Illustration du cercle vicieux de la théorie des X

La théorie des Y repose sur l’idéologie inverse selon laquelle l’individu est motivé par le travail. Il

adopte donc un comportement positif se traduisant par une forte implication personnelle dans

Construction de règles strictes et

de contrôles

Adaptation des collaborateurs par le travail

minimum

Fuite du collaborateur

fâce à ses responsabilités pour éviter les

prises de risques

Renforcement des convictions des dirigeants

fâce à la passivité des

collaborateurs

Adoption d'une stratégie de mangement

paternaliste et directif


[53]

l’entreprise au travers d’une prise de participation et de responsabilités. Dans cette théorie

l’efficacité des collaborateurs dépend de la capacité de la direction à créer un climat de confiance

propice à l’enrichissement et l’épanouissement de ses collaborateurs. Ainsi, l’effort physique et

mental est une chose naturelle pour un être humain, tout comme la pratique de loisirs. L’individu se

sentira également responsable de la réussite de son entreprise et cherchera inévitablement à fournir

le meilleur de soi. Plusieurs points de supposition sont mis en avant dans cette théorie :

- Un homme fournit naturellement des efforts physiques et mentaux ;

- L’homme n’est pas nécessairement plus productif sous la menace ;

- La motivation du collaborateur augmente selon la satisfaction qu’il retire de son métier ;

- Tout homme est capable d’apprendre ;

- Dans un contexte adéquate, l’homme cherche à prendre ses responsabilités ;

- L’homme a besoin de travailler pour se construire ;

- Il est préférable de laisser les collaborateurs s’organiser par eux même.

Cette théorie génère un cercle vertueux dans lequel la collaboration entre les employés et les

dirigeants contribue de façon naturelle à l’accroissement de la motivation des collaborateurs ainsi

qu’à leur prise de responsabilités.

Figure 26 : Illustration du cercle vertueux de la théorie des Y

Intégration des principes de

confiance et de délégation

Augmentation de l'implication

des collaborateurs

Constatation des prises de

responsabilité

Renforcement des convictions des dirigeants

fâce à la délégation et la

confiance

Adoption d'une stratégie de

management basée sur la confiance et l'autonomie


[54]

Nous pouvons en conclure que l’attitude des dirigeants influencera bien sûr la façon de travailler des

collaborateurs mais également leur comportement au quotidien. Dans les services informatiques,

nous vérifions dans la quasi-totalité des cas la théorie des Y. Les collaborateurs sont intrinsèquement

motivés par leur métier, souvent associé à une passion pour eux, et évoluent dans un climat de

confiance reposant sur des principes d’auto motivation, de prise de risques, de prise de

responsabilités et de confiance envers les capacités des collaborateurs. Il est donc important de

retenir que dans un contexte quaternaire la bonne attitude à adopter concernant le pilotage des DSI

repose sur la conviction que les collaborateurs sont motivés par le travail, que la délégation des

responsabilité permettra à l’employé d’être épanoui et donc performant.

2.4.3. Les sphères de contrôle et d’influence

Les sphères de contrôles et d’influences sont un concept de management visant à évaluer et

renforcer les domaines de compétence d’un individu intégré à l’organisation et de mettre en

évidence les choses qu’il peut totalement contrôler, influencer ou les autres points qui le concernent

directement.

Figure 27 : Sphères de contrôle, d'influence et d'intérêts

Le concept repose sur trois niveaux d’influence :

- Sphère de contrôle : Ce point concerne toutes les responsabilités prises par le collaborateur

dans l’organisation. Ce sont des compétences qu’il maitrise parfaitement et pour lesquelles

l’individu a l’obligation de traiter.

Sphère d'intérêts

Sphère d'influence

Sphère de contrôle


[55]

- Sphère d’influence : Cette zone met en avant les tâches ou les problèmes liés à l’organisation

sur lesquels le collaborateur a la possibilité d’influencer. Il peut ainsi prendre des décisions

qui impacteront l’entreprise.

- Sphère d’intérêt : Cette sphère comprend toutes les questions et tâches qui concernent de

près ou de loin le collaborateur. Cependant il n’a pas la possibilité de les influencer ou de les

contrôler.

L’analyse des sphères de contrôle et d’influence permet de disposer d’une vision sur l’importance du

collaborateur dans la structure. Elle permet également d’établir l’importance de l’individu dans

l’organisation. En effet, plus ses sphères de contrôle et d’influence seront importantes, plus le

collaborateur participera à la réussite de l’organisation. Cette technique peut être utilisable dans le

cadre d’une réorganisation ou de changements importants dans l’organisation afin de détecter les

potentiels nouveaux leaders ou collaborateurs qualifiés sur la maitrise des environnements de

travail.

2.4.4. La gestion du comportement des collaborateurs

Cette composante managériale ne repose sur aucune théorie psychologique mais sur une analyse

factuelle des comportements sociaux professionnels au travail. Sa maitrise n’en demeure pas moins

indispensable dans les organisations IT pour mener à bien l’intégration d’un changement conséquent

dans l’organisation. La gestion du comportement consiste à analyser les comportements de chaque

individu dans l’organisation et mettre en œuvre les axes d’amélioration afin d’atteindre le résultat

souhaité permettant la réussite de l’entreprise. Concrètement, la gestion des comportements se

focalise sur les zones de maitrises de compétences du collaborateur et ses états émotionnels.

Les zones de maitrise se composent de trois niveaux échelonnant le comportement de l’individu par

rapport à ses compétences globales relatives à l’exercice de sa profession :

- La zone de confort : C’est avant tout une attitude face aux différentes situations de la vie

professionnelle. Elle consiste à se protéger en évitant de sortir de la routine de travail qui

s’est installée progressivement depuis l’intégration du collaborateur dans l’entreprise.

- La zone d’apprentissage : Il s’agit de la zone intermédiaire entre la zone de confort et celle de

panique. Elle révèle un doute ressenti par le collaborateur pour exercer son activité.

L’individu ne sait pas encore s’il est capable de mener à bien sa mission. Dans cette zone,


[56]

chaque situation est une occasion d’apprendre, indépendamment du résultat final. Lorsque

le collaborateur aura accompli avec succès les nouvelles tâches confiées, il se sentira

suffisamment maitre de soi et repassera en zone de confort.

- La zone de panique : C’est la zone la plus éloignée du confort. Si le collaborateur se situe à

l’intérieur de cette zone, cela signifie qu’il n’arrive plus à gérer ses émotions. Il a donc perdu

la maitrise de soi et ne sait pas comment se redresser. La panique, l’anxiété et la peur

paralysent le collaborateur au point que tout apprentissage et réalisation sont désormais

devenus impossibles. Cette zone est très néfaste pour le collaborateur et se ressent au

niveau de l’organisation.

Figure 28 : Les zones de maitrise

Il convient ainsi pour les manageurs de définir le bon comportement à adopter afin d’utiliser au

mieux les capacités du collaborateur. Pour cela il est nécessaire de réaliser conjointement avec le

collaborateur un bilan des compétences incluses dans sa zone de confort, d’apprentissage de

panique. L’objectif final est d’agrandir toujours plus la zone de confort et d’éviter tout débordement

en zone de panique. Le manageur prendra ainsi conscience des formations à dispenser aux

collaborateurs et des objectifs annuels à court et moyen termes à définir. Le manageur doit ainsi

faire preuve d’objectivité dans l’attribution de nouvelles tâches au collaborateur afin de les inclure

en juste quantité car elles se positionneront dans la zone d’apprentissage. Il devra ainsi laisser le

temps au collaborateur d’assimiler les nouvelles compétences avant de lui confier de nouvelles

missions. Cela évitera tout débordement en zone de panique et assurera la productivité ainsi que la

qualité de travail de son employé.

Zone de panique

Zone d'

apprentissage

Zone de confort


[57]

Par ailleurs, des études réalisées sur les comportements humains dans les entreprises ont révélé que

les hommes peuvent passer par 9 états émotionnels différents au travail. Si certains états facilitent la

performance, d’autres sont réellement néfaste à l’organisation. Encore une fois, le manageur devra

juger correctement la situation actuelle pour positionner ses collaborateurs dans un état émotionnel

propice à une performance optimale.

Les 9 états émotionnels sont les suivants :

Compétence faible Compétence moyenne Compétence élevée

Ch

alle

nge

éle

vé

L’anxiété

Etat mental qui apparait lorsque le collaborateur réalise une activité qu’il ne maitrise pas, ce qui lui génère de l’appréhension. Dans les cas extrêmes le collaborateur peut faire un burn-out lors de cet état.

L’excitation

Etat psychologique éprouvé lors de l’attribution d’un challenge dont la difficulté est supérieur à la moyenne. Souvent relatif à un intérêt élevé pour l’activité ou le projet.

Le flow

Etat mental atteint par une personne lorsqu’elle devient complètement immergée par son activité. L’engagement au service de l’entreprise devient alors total.

Ch

alle

nge

mo

yen

L’inquiétude

Etat phycologique éprouvé face à un challenge moyen dont l’intérêt porté au projet est moyen. Le collaborateur ne maitrise pas ses tâches.

Neutre

Etat basique lorsque le collaborateur réalise une mission à difficulté modérée avec des compétences moyennes. Aucune émotion particulière n’est donc ressentie

La maitrise

Etat psychologique atteint lors de la réalisation d’un challenge moyen, inférieur aux compétences du collaborateur. L’intérêt pour l’activité est modéré.

Ch

alle

nge

fai

ble

L’indifférence

Etat psychologique observé lorsque le collaborateur intervient sur des tâches simples et sans rapport aux compétences possédées.

Le détachement

Etat mental éprouvé lorsque les missions ne correspondent pas aux attentes de l’individu.

L’ennui

Etat psychologique apparaissant lorsque le collaborateur possède un niveau de compétence trop élevé par rapport à ses missions.

Figure 29 : Matrice des neuf états émotionnels

Dans une optique de qualité et de performance il convient aux dirigeants d’adopter un équilibrage

entre les tâches confiées et le niveau de qualification du collaborateur. Le manageur devra dans un


[58]

premier temps s’appuyer les zones de maitrise du collaborateur pour ensuite attribuer les tâches en

fonction de ces dernières. Cela permettra de réguler l’état émotionnel du collaborateur pour le

placer dans un état d’esprit adapté optimal. Il en découlera un fort impact sur la performance et

donc par extension sur la qualité du travail fournit. Ce point est à prendre en considération

particulièrement sur des projets complexes multi-acteurs afin que chaque participant prenne à cœur

son rôle. Par ailleurs, si les collaborateurs sont dans un bon état d’esprit, les chances de respecter les

délais seront considérablement accrues.


[59]

3. L’industrialisation du SI par DevOps

3.1. Développer la culture DevOps

3.1.1. Construire la confiance

La confiance est une valeur clé du mouvement DevOps, et probablement la plus difficile à mettre en

œuvre. Il n’est bien sûr pas envisageable de demander aux collaborateurs de se faire confiance et

d’attendre quelques jours que ces derniers le fassent. Les résultats seraient totalement nuls.

Avant de rentrer dans d’avantage de précisions il est essentiel de comprendre quels acteurs sont

concernés. C’est très simple, tous les acteurs amenés à collaborer ensemble doivent se faire

confiance professionnellement. Il faut donc construire une relation de confiance

développeurs/opérationnels, testeurs/développeurs, testeurs/opérationnels mais aussi

manageurs/collaborateurs. Il ne faut pas non plus négliger les autres intervenants éventuels tels que

les architectes ou les responsables de méthodes.

Figure 30 : Schéma de confiance entre les principaux acteurs IT

La patience doit être de rigueur avant d’obtenir une totale confiance entre les acteurs. Pour

construire cette relation saine il faut s’axer sur l’aspect humain de chaque individu. En dehors du

contexte professionnel, chaque être humain est génétiquement programmé pour interagir avec ses

congénères et à établir des relations durables. Ainsi, certaines situations professionnelles permettent

de développer cette composante sociale :

- Lors de formations internes, notamment sur les concepts DevOps, il peut être opportun de

réunir les participants dans un lieu original ou amusant. Mixer la population avec des

administrateurs, des développeurs, des manageurs et d’autres profils permettra dans un

Manageurs

Développeurs

Testeurs

Opérationnels


[60]

premier temps de créer des liens. Il faudra ainsi laisser place à des moments d’échanges lors

de la formation pour que les participants puissent se côtoyer dans un contexte semi-

professionnel. C’est seulement en cassant les habitudes que les participants pourront se

découvrir sous un autre angle.

- La création de challenges techniques avec des équipes mixtes permettrait également de

resserrer naturellement les liens entre les participants tout en développant leurs

compétences au travers de leurs découvertes sur le sujet.

- Lors de la participation à des conférences ou séminaires louer un hôtel équipé d’un bar, d’un

restaurant et d’activités sportives permettra de rassembler les participants avec convivialité

et bonne humeur.

- En cas de participation à des forums professionnels, faire contribuer des acteurs de chaque

services ensemble pour mener à bien la réussite du forum.

- La mise en place d’activités sportives ou extra-professionnelles permettra également

d’entretenir les bonnes relations sur le long terme.

- L’organisation d’échanges de collaborateurs d’une durée de plusieurs semaines entre les

services apportera un double bénéfice à l’entreprise. Les collaborateurs prendront

conscience des contraintes et motivations des autres équipes tout en améliorant

considérablement leurs connaissances sur l’organisation interne de la DSI.

- Les manageurs doivent impérativement bien réfléchir aux promesses faites à leurs

collaborateurs. Le fait de ne pas respecter ses engagements détruira la confiance qui s’est

installée. Il en va de même pour tous les autres acteurs de la DSI.

- Il peut être également envisageable de programmer des repas annuels interservices ou lors

de la réussite de projets importants pour remercier les participants et profiter de cette

occasion pour les réunir avec convivialité.

- Des lieux d’échanges et de partages collectifs doivent également être installés dans les

locaux de la société pour que les collaborateurs puissent se côtoyer régulièrement. Ces lieux

peuvent être multiples : salles de pause, espaces fumeurs, coins café, restaurant

d’entreprise, jardins aménagés, etc.

En respectant les astuces énoncées ci-dessous, la confiance devrait s’installer progressivement sur le

long terme. Il est impératif de maintenir cette relation avec des activités sociales mixtes régulières.

Toutefois l’installation de la confiance peut être plus ou moins rapide en fonction du contexte. Une

petite structure bénéfice d’une qualité humaine innée. Les acteurs étant peu nombreux, les contacts

se multiplient rapidement et instinctivement entre toutes les parties de l’organisation. Les


[61]

collaborateurs ont également l’habitude de travailler régulièrement ensemble et de se côtoyer au

quotidien. Par ailleurs, les personnalités de chaque individu présent dans la structure est à prendre

en compte. Les individus à tendances introverties ont généralement plus de difficultés pour se

rapprocher des autres, la confiance s’installera alors plus lentement. Enfin un turn-over important

des ressources humaines génère un climat d’instabilité et ralenti fortement le développement des

relations internes. Il faut du temps pour qu’un nouveau collaborateur se sente parfaitement intégré

dans l’entreprise et pour que les autres apprennent à le connaitre.

3.1.2. Générer de la transparence

La transparence entre les services est en quelque sorte un accélérateur de gestion de projets. Elle

permet au chef de projet de disposer d’une vision globale et précise sur l’avancement des tâches de

chacun. A l’inverse, un manque de communication interne corrompra les échanges d’informations

qui ne seront plus transparentes mais non diffusées. La conduite du projet deviendra risquée et

difficile à mettre en œuvre. Cela peut rapidement être une cause d’échec sur un projet IT.

La transparence repose sur plusieurs concepts :

- Être factuel : chaque prise ou échange d’information se doit de rester factuelle, c’est-à-dire

basée sur des faits concrets et non des sentiments, des impressions ou encore des

hypothèses. Plus l’information sera concise, plus elle sera claire et donc transparente. Elle ne

doit aucunement être sujette à une interprétation.

- Une bonne communication verticale et horizontale : la communication doit être

multidirectionnelle et identique. Un collaborateur doit informer son supérieur de

l’avancement de ses tâches régulièrement mais doit également communiquer avec les autres

équipes du projet. Ainsi, tout le monde disposera de la même information, ce qui permet de

gagner en efficacité par une meilleure organisation.

- L’exhaustivité dans les rapports d’état : un rapport d’avancement se doit d’être exhaustif. Le

fait de ne pas communiquer toutes les informations nécessaires peut être réellement

pénalisant ou dans le pire des cas mal interprété. Il ne faut pas non plus être dans la sur-

communication mais un oubli d’information peut impacter le projet, créer des redondances

dans la réalisation d’activité et pénalise la circulation de l’information.

- Ne pas censurer ses propos : chaque individu doit pouvoir communiquer sans crainte de

jugement, même si une tâche n’a pas avancée. Des solutions correctives pourront ainsi être

mises en œuvre.


[62]

3.1.3. Œuvrer pour la coopération Dev - Ops

Cette valeur est l’essence même du mouvement DevOps. Elle est donc primordiale à la réussite de

l’intégration de la culture. Rappelons la problématique initiale :

- Les développeurs n’ont pas confiance envers les connaissances des opérationnels concernant

la gestion des plateformes de production et pensent qu’ils ne savent pas correctement

investiguer sur l’apparition des éventuels incidents.

- Les opérationnels n’ont pas confiance envers les développeurs sur la stabilité et l’efficience

de leurs programmes.

- Le produit du croisement de ces deux constats génère des conflits perpétuellement

répétitifs.

Pour atténuer ces différences et favoriser la coopération, il faut tout d’abord se concentrer sur le

savoir-être de chaque acteur. Le savoir être se compose de la personnalité de l’individu et de la

maitrise de son périmètre.

Figure 31 : Les composantes de la compétence

Ainsi, les acteurs IT devront fournir un effort supplémentaire sur leur personnalité pour montrer aux

autres équipes qu’ils maitrisent leur domaine de compétences. Les collaborateurs devront donc

mettre entre parenthèse les conflits existants le temps que la culture DevOps se répande

progressivement. Les mauvais comportements sont donc à proscrire, voir à sanctionner, sans quoi la

coopération ne sera jamais réellement possible.

Savoir

•Culture générale

•Savoirs professionnels

Savoir-faire

•Mise en pratique

•Expériences

Savoir-être

•Personnalité

•Maitrise du périmètre


[63]

La deuxième étape consiste à encourager la collaboration entre les deux parties. L’objectif est

maintenant d’atténuer les doutes respectifs pour embrasser pleinement la collaboration. Pour cette

étape, plusieurs points peuvent être abordés :

- Encourager l’utilisation des outils de communication numériques mais en évitant dans la

mesure du possible les eMails. Les forums et messageries instantanées doivent être

copieusement utilisés et quotidiennement.

- Encourager la communication orale directe en face à face dès que possible. La mise à

disposition des salles de réunion ou un réagencement des locaux pourrait être bénéfique.

- Eviter d’utiliser des casques téléphoniques ou d’écouter de la musique par écouteurs pour

faciliter l’échange et la communication. Si les collaborateurs souhaitent travailler en musique

il est possible d’installer une radio ou une chaine HiFi collective réglée sur un volume sonore

modéré.

- Installer des tableaux blancs dans les espaces de travail pour encourager les collaborateurs à

partager leurs idées, être créatifs et échanger facilement par des schémas.

- Mélanger les sujets de discussion entre les équipes. Cela permettra de retirer des avis

différents et de partager des thématiques au service de causes communes. Les acteurs

retrouveront le sentiment de travailler pour un objectif plus global.

La troisième étape consiste à modifier lentement les perceptions des collaborateurs sur les risques

liés à la réalisation des projets et sur leur façon de collaborer :

- Un bon début serait de commencer à mettre en œuvre des processus de développement

continu en mode DevOps sur quelques projets simples avec des acteurs très performants et

non réfractaires aux changements. Ils démontreront ainsi la faisabilité et l’efficacité du

système.

- Ensuite, l’idéal serait de débuter un nouveau projet IT de grande envergure en utilisant les

mêmes procédés. Ce sera l’occasion pour toute la DSI de suivre l’avancement du projet par

rapport à sa conduite. Il est également envisageable d’offrir l’opportunité aux collaborateurs

externes au projet de contribuer et d’ouvrir les réunions au publique

- Une fois que les compétences ont été assimilées par les ingénieurs pilotes de ce changement,

les inciter à publier des informations sur l’intranet ou sous forme de nouvelles à propos de

leurs impressions, des outils qu’ils ont utilisés ou encore sur des conseils, le temps passé, etc.


[64]

- Lors de la réalisation d’un projet pilote il est pertinent de capturer un maximum

d’informations statistiques ou de mesures puis de les publier par la suite. Cela démontrera à

tous l’efficacité du système par une démonstration scientifique.

- Enfin, lorsque les projets pilotes sont terminés, il serait intéressant de publier un REX (retour

d’expérience) ou un court compte rendu explicatif sur les nouveautés utilisées.

Enfin, la dernière étape consiste à modifier légèrement les intentions des deux parties en vue de les

rassembler au service de la cause commune. Comme pour les points précédents il n’existe pas de

techniques précises vérifiables mais le principe repose sur du bon sens.

Intention Avantages Inconvénients

Faire adopter les valeurs

DevOps de la même façon

pour les Dev et les Ops

DevOps et la pratique du CD

deviendra une norme générale.

Les collaborateurs possèderont

les mêmes connaissances sur

DevOps.

Les acteurs IT risqueraient de

penser que la rapidité du

changement est plus

important que la qualité.

Modifier les objectifs

d’équipes au profit d’objectifs

communs aux Dev et aux Ops.

Les inciter à les respecter par

la mise en place de bonus

financiers ou matériels

Les collaborateurs seront très

motivés par rapport à la

réussite collective. Le seul

moyen d’obtenir la

récompense pour les deux

parties sera de collaborer

Si le bonus n’intéresse pas tous

les collaborateurs, des conflits

risquent d’apparaitre en

addition de ceux déjà existants

Remplacer la totalité de la

culture actuelle interne par

une culture DevOps

Potentiellement, le respect

total des valeurs et principes

DevOps conduirait la DSI à

atteindre l’excellence et la

sérénité

Concrètement, le changement

est très difficile à conduire et

toute société est attachée à ses

valeurs, ses habitudes.

Un changement brutal

déstabiliserait les

collaborateurs mais aussi les

manageurs.

Figure 32 : Matrice des avantages et inconvénients de modification des intentions


[65]

3.1.4. Empêcher les blâmes inconvenants

Selon la culture DevOps, le temps dépensé à blâmer autrui pour ses erreurs est du temps

d’apprentissage gaspillé. Or la gestion du temps est un défi majeur pour chaque acteur IT. Il ne peut

donc être toléré de l’utiliser à mauvais escient. L’apprentissage et l’autoformation sont des étapes

indispensables pour atteindre un niveau de compétence élevé dans un contexte environnement très

changeant.

Figure 33 : Comparaison vs Blâme

De plus, le blâme est un moteur de productivité négatif qui génère un cercle vicieux de l’échec. Plus

des reproches sont exprimés vers un collaborateur, plus il pense être incompétent, moins il est

performant et plus il se le reproche. La boucle recommencera indéfiniment tant qu’il ne recevra pas

de félicitations pour la réussite de son travail.

Figure 34 : Le cercle vicieux de l'échec

Apprenstissage vs blame

Apprentissage Blame

"Tu es mauvais"

"Je suis incompét

ent"

"Je n'y arriverai

pas"

"Je n'y arrive pas"

"Je suis mauvais"


[66]

Pour éviter ces attitudes négatives, les collaborateurs doivent adopter un code de bonne conduite :

- Accepter que des erreurs puissent arriver ;

- Encourager l’échec rapide pour apprendre plus vite de ses erreurs ;

- Encourager la responsabilisation des acteurs ;

- Encourager l’ouverture d’esprit et l’honnêteté en partageant ses expériences ;

- Ne pas exagérer l’ampleur d’une erreur commise ;

- Se concentrer sur les points positifs.

A l’inverse, les attitudes négatives sont à bannir :

- Ne pas se moquer de ses camarades ;

- Ne pas rejeter des fautes sur quelqu’un ;

- Ne pas blâmer un individu pour ses erreurs avant de connaître les faits ;

- Ne pas arrêter l’innovation pour réduire les risques d’erreurs.

La mise en œuvre de ces consignes permettra de réduire les blâmes inutiles dans les organisations

internes. Cependant, certaines personnalités continueront toujours à persister dans cette voix. Des

sanctions exemplaires devront être mises en place pour bannir définitivement ces comportements.

3.1.5. Encourager l’innovation

L'innovation peut se définir comme une amélioration continue de l'existant de façon radicale. Cet

aspect est fondamental dans le mouvement DevOps mais devrait également l'être dans toutes les

structures et organisations à finalité technologique. L'informatique est un domaine très mutagène

qui est en perpétuelle évolution. Ne pas innover revient à rester bloqué dans le temps et donc à

prendre du retard face aux concurrents.

Plusieurs techniques permettent d'encourager l'innovation dans les organisations internes :

- Stimuler la créativité : les collaborateurs possèdent tous une part de créativité. Par ailleurs, la

réalisation des objectifs est prioritaire sur le reste. Ce qui induit généralement que la volonté

d'amélioration est mise de côté au profit de la réalisation des tâches courantes et sur le long

terme cette volonté tend à se réduire de plus en plus. Les manageurs doivent alors retrouver

cette créativité en stimulant les collaborateurs au travers de sessions de brainstorming. Il

peut être aussi envisageable d'installer des boites à idées ou des réunions d'innovation.


[67]

- Récompenser les bonnes idées : l'innovation est le moteur de l'informatique et peut parfois

représenter une véritable opportunité commerciale. Un système de récompense incitera les

collaborateurs à réfléchir intensément sur les possibilités d'amélioration. Il est alors logique

de récompenser un individu qui a fourni un effort supplémentaire et qui a fait preuve

d'intelligence. Google est un exemple de réussite, les collaborateurs retirent beaucoup de

satisfaction à participer à la création de nouveaux produits au sein de la firme. Visiblement

c'est un système qui fonctionne.

- Sortir de la zone de confort : comme étudié dans le paragraphe 2.4.4 "la gestion du

comportement des collaborateurs", les DSI ne peuvent se permettre de laisser les

collaborateurs dans une zone de confort routinière, impropre à l'innovation. Il est donc

important d'attribuer régulièrement de nouvelles tâches qui ne sont pas encore maitrisées.

Ce processus d'apprentissage régulier habituera progressivement les individus à prendre des

risques et à mieux appréhender le changement

- Maintenir une veille technologique : la veille est une étape indispensable pour innover. Elle

permet de se tenir informé sur les nouvelles technologies et les tendances à venir. Il est ainsi

plus aisé d'anticiper les changements et de définir le moment opportun pour œuvrer. C'est

également une excellente façon de récupérer des idées d'améliorations possibles. Cependant

le temps est souvent compté pour les collaborateurs. Il peut alors être intéressant de définir

des horaires fixes dédiés à la recherche d'innovation. Enfin, de nombreux webinar fleurissent

sur internet. C'est ainsi l'occasion de les suivre en groupe mixtes ou par équipe puis

d'échanger sur les informations qui seraient intéressantes à mettre en œuvre.

- Participer à des conférences et des séminaires : c'est aussi l'occasion d'échanger avec les

autres sociétés venues assister aux présentations. Ces moments sont riches en échanges et

très formateurs. Les participants reviennent souvent avec une liste d’améliorations possibles.

C'est donc un formidable centre d'innovation et de recherche. De plus, dans certaines

situations, il sera possible de se créer des contacts intéressants et dans ce domaine d'activité

avoir des contacts permet de partager des retours d'expériences qui permettent de vérifier

l'utilité d'une pratique ou d’une solution avant de la mettre en œuvre.

L'innovation est donc une composante nécessaire pour chaque métier IT. Elle se révèle aussi utile

pour les collaborateurs que pour la structure toute entière.


[68]

3.2. Conduire le changement

3.2.1. Appréhender le changement en douceur

Nous savons que le changement génère du stresse et de l'anxiété chez le collaborateur mais que le

stresse est néfaste à la qualité et à la performance. Toutefois le changement est nécessaire, il est

porteur d'innovation. Le fait même de disposer d'un champ de vision partiellement incertain

demande un effort d'adaptation supplémentaire. Les manageurs doivent alors faire preuve de

justesse dans la conduite du changement. Pour cela, il existe une technique mnémotechnique

utilisée en gestion de projets et en management permettant de définir un objectif idéal : S.M.A.R.T.

pouvant être amélioré en S.MA.R.T.E.R. Chaque lettre correspond à un critère de définition de

l'objectif.

Concrètement, un objectif se doit d'être S.M.A.R.T.E.R. :

- Spécifique (ou Simple) : l'objectif fixé doit être clair, détaillé et concret.

- Mesurable : par des mesures précises permettant d'établir l'avancement et la réussite.

- Accessible (ou Atteignable/Acceptable) : l'objectif doit être adapté aux compétences, à

l'expérience et aux moyens du collaborateur.

- Réaliste : le collaborateur doit être en mesure de réaliser l'objectif. Mais cela n'empêche pas

qu'il puisse représenter un challenge.

- Temporellement défini : il est nécessaire de fixer une date buttoir et si besoin un échéancier

pour les étapes intermédiaires.

- Evaluable : le travail engagé par le collaborateur doit pouvoir être évalué par ses supérieurs.

On peut également noter qu'un autre terme est parfois utilisé : Excitant (l'objectif doit

représenter un challenge motivant pour le collaborateur). Toutefois, il ne serait pas

contradictoire de prendre en compte le paramètre "évaluable" et "excitant" lors de la

définition d'un objectif.

- Réajustable : l'objectif doit être réajustable après avoir été attribué à un collaborateur dans

le but de pallier à d'éventuelles modifications imprévisibles. On retrouve parfois l'utilisation

du terme Récompensé impliquant que l'atteinte des objectifs devrait être gratifiée pour le

réalisateur.

Par cette méthode, le changement devrait être adapté aux capacités des collaborateurs. Il est

possible en informatique d'augmenter légèrement les ambitions de ces objectifs pour que les

collaborateurs aient l'impression de relever un challenge intéressant mais accessible. Cette légère


[69]

augmentation représentera un réel accélérateur de motivation. Comme expliqué dans le paragraphe

2.4.4 par la matrice des neufs états émotionnels, l'excitation, le flow et la maitrise sont des états

idéaux. De plus les professionnels de l'informatique ont une tendance particulièrement élevée à la

stimulation par des challenges intellectuels difficiles.

Une bonne connaissance de ses collaborateurs est indispensable pour fixer des objectifs atteignables.

Sans quoi un risque de décalage des objectifs par rapport aux compétences réelles des collaborateurs

serait néfaste sur l'individu et par extension sur la conduite du changement globale.

3.2.2. Le processus de transition personnelle

De multiples articles traitent de la transition personnelle liée à un changement important impactant

les façons de travailler. John Fisher a détaillé les différentes étapes que parcours un individu en

réponse à un changement radical de ses méthodes de travail. Ainsi, dans une situation « normale »

un individu traverse neuf étapes émotionnelles composées de sentiments positifs et négatifs. Cet

ascenseur émotionnel doit par conséquent être suivi et maitrisé pour que le changement aboutisse.

Un individu peut également s’égarer par des chemins transverses qui sont tous considérés comme

des échecs.

Figure 35 : Le processus de transition selon John Fisher, 2012


[70]

Selon la figure n°36, les différentes étapes émotionnelles menant au succès sont les suivantes :

- L’anxiété (anxiety) : l’individu est stressé par rapport aux efforts à fournir.

- Le bonheur et l’excitation (happiness) : l’individu a l’impression de participer à la conduite du

changement.

- La peur (fear) : l’individu est effrayé par les conséquences du changement.

- La menace (threat) : l’individu se sent menacer par le chemin restant à parcourir.

- La culpabilité (guilt) : l’individu a l’impression d’être dépassé par les évènements.

- La dépression (depression) : l’individu est dans un état d’esprit extrêmement négatif, il se

sent démuni.

- L’acceptation (gradual acceptance) : l’individu se redresse pour pouvoir embrasser le

changement.

- L’élévation (moving forward) : l’individu a parfaitement assimilé le changement et se sent

prêt à poursuivre son travail ou entamer un nouveau changement.

Par ce schéma, nous pouvons constater l’apparition de plusieurs étapes sensibles pouvant mener à la

dérivation :

- L’étape du bonheur peut conduire l’individu à entrer dans une phase de déni total. L’individu

considère alors que le changement est négligeable car il en sous-estime la difficulté. Cette

étape est sans issue tant que le collaborateur ne prendra pas conscience que le changement

bouleversera ses habitudes et qu’il devra fournir des efforts supplémentaires pour s’adapter.

- L’étape de la menace peut conduire vers la désillusion ou vers l’hostilité. La désillusion

consiste à ce que l’individu doit déçu par les premiers résultats du changement et que par

conséquent il ne souhaite plus participer dans ce processus. La désillusion tend

généralement à s’estomper rapidement lorsque ses confrères auront accepté et intégré le

changement dans leur mode de fonctionnement. Le collaborateur sera alors incité

inconsciemment à essayer de reproduire les mécanismes de ses prédécesseurs. L’hostilité est

quant à elle bien plus néfaste pour l’individu. Après être passé par une phase de dépression,

le collaborateur ressent de la colère vis-à-vis du changement. Ce sentiment est issu d’une

impression infondée par laquelle le changement d’apportera rien de positif au collaborateur

sur un plan personnel. Il se défend alors mécaniquement en opposant une forte résistance.

Lors de cette étape, les manageurs doivent reconvaincre l’individu que le changement sera

bénéfique. Il recommencera alors une nouvelle boucle de transition personnelle depuis le

début


[71]

Ces différentes hypothèses constituent un risque important pour le succès de l’intégration de

DevOps dans une organisation interne. De plus chaque individu réagit différent et accompli le

processus de transition plus ou moins rapidement. Les manageurs se doivent d’accompagner et

soutenir leurs collaborateurs dans ces étapes par un suivi individuel. Ce point est d’autant plus vrai

peu après l’annonce du changement, lors de la phase de réalisation, lorsque le collaborateur est

vulnérable.

3.2.3. Adopter un style de management adapté

DevOps est une culture dotée nombreuses valeurs et de principes forts. Elle impose à toute une

structure de suivre des règles au profit d'une promesse d'amélioration de l'intégralité de

l'environnement de travail. Cependant, lors de l'intégration de DevOps, un potentiel conflit majeur

est susceptible de prendre forme. La culture IT DevOps s'opposera à la culture managériale en place.

Ces deux cultures ne sont pas nécessairement incompatibles. Mais les chances sont faibles pour que

les deux le soient pleinement. Il faut alors faire des concessions et définir les priorités.

Le style délégatif est un bon exemple de compatibilité. Au travers de ce style de management, les

dirigeants tentent de stimuler la créativité des collaborateurs et de consolider la solidarité des

équipes. Ainsi, dans le cadre d'un contexte délégatif, les décisions sont prises en équipe. Les

participants deviennent donc à terme autonomes et responsables. Ces deux qualités font partie

intégrante de la philosophie DevOps. De plus le bon fonctionnement de cette méthode repose sur la

relation de confiance entre les participants à l'échelle de l'équipe. Ce qui représente un nouveau

point de similitude. En revanche ce style génère inévitablement un manque de structure dans

l'exercice d'une activité car les individus ne subissent aucune pression et sont entièrement libres de

leurs décisions. Ce qui peut être problématique sur le long terme.

Le style démocratique, ou participatif, est également compatible. Les dirigeants tentent de favoriser

les échanges et les réflexions de groupe. En revanche le manageur est celui qui tranche pour la

décision. Ce mode de management se révèle être particulièrement efficace pour motiver les

collaborateurs, stimuler leur créativité et mieux appréhender des projets complexes par des

constructions collectives. Cependant des conflits intra équipes peuvent apparaitre à cause d'une

forte compétitivité entre les participants qui souhaitent se démarquer pour obtenir la

reconnaissance du supérieur.


[72]

Par ailleurs il est important de comprendre qu'un style de management ne se définit pas seulement

par la volonté de le mettre en œuvre ou non. La personnalité du manageur et celle de ses

collaborateurs complexifie énormément les façons de piloter des équipes. Ainsi, chaque individu est

à traiter de façon spécifique. Si la culture managériale générale tend vers un style démocratique, il

est néanmoins possible de piloter certains collaborateurs de façon directive. Cela peut s'avérer utile

pour des employés peu compétents, sur des individus introvertis ou encore sur des stagiaires ou des

jeunes diplômés récemment intégrés.

Enfin, le choix des styles de management conduira l'entreprise vers une culture DevOps plus ou

moins variable. Le style délégatif favorise l'innovation, la prise de risque et la responsabilisation des

acteurs. Alors que le style démocratique stimule l'innovation, diminue la peur de l'échec, encourage

les bons comportements et favorise la collaboration. Il est donc nécessaire de réfléchir sur les

aspects que l'organisation souhaite améliorer pour réaliser les meilleurs choix stratégiques par la

suite.

3.3. Choisir ses outils

3.3.1. Les critères de sélection

Le choix des outils DevOps est une tâche extrêmement complexe. Le fleurissement des applications

DevOps est réellement exponentiel. De plus, les outils sont encore très récents et sont donc amenés

à évoluer ou être remplacés par de nouveaux outils toujours plus performants. Par ailleurs ils

constituent une modification radicale du concept même des métiers de développeurs et

d’administrateurs systèmes. Si la finalité des professions reste la même, la façon de les pratiquer est

différente. Il est donc nécessaire d’accompagner l’intégration des outils DevOps dans le cadre d’une

campagne lente et maitrisée.

Pour réduire les risques liés à l’intégration d’une solution inadéquate, il est primordial de se poser les

bonnes questions :

- L’outil est-il adaptable à l’infrastructure actuelle ?

- L’outil répond-il efficacement aux besoins ?

- L’outil est-il sécurisé ?

- Les retours d’utilisation sont-ils bons ?

- Le produit est-il évolutif ?

- L’outil peut-il s’interfacer avec d’autres produits pour générer des synergies ?


[73]

- L’outil est-il suffisamment ergonomique pour être utilisé par les collaborateurs ?

- En cas de solution open source, la communauté est-elle active ?

- L’outil répond-il aux critères d’automatisation fournit par le « continuous delivery » ?

- L’outil est-il en phase avec la culture DevOps ?

- Le coût d’achat et d’intégration de l’outil rentre-t-il dans le budget défini ?

- Un centre de support permet-il de disposer d’une garantie d’utilisation ?

Si la plupart de ces questions peuvent être répondues par l’affirmative alors le produit à de grandes

chances d’être en parfaite adéquation aux besoins internes. Le cas échéant il peut être envisageable

d’attendre le développement d’un outil adapté, de collaborer sur des projets open source, de

développer un produit en interne ou encore de faire appel à un prestataire externe pour réaliser un

outil sur-mesure.

3.3.2. Un contexte favorable à l’open source

Les outils DevOps sont à l’heure actuelle principalement destinés aux plateformes open source. Ce

phénomène est explicable par la nature même du concept des environnements Unix-like. La

communauté « Linuxienne » est moteur de l’innovation informatique. Le développement de projets

communautaires est facilité par la coopération d’acteurs issus de toutes origines. Aucune barrière

n’empêche donc le développement novateur car aucun investissement financier n’est généralement

exigé, ou alors il est négligeable. Seul du temps de développement bénévole est engagé. Ce

phénomène est généralisé, il ne s’applique pas seulement pour DevOps. D’un point de vue général,

de nombreux outils apparaissent sur Linux avant d’être développés pour Windows et Mac OSX.

Des portages de compatibilités sont à prévoir dans les mois ou années à venir. Le renouvellement des

gammes serveurs de Windows permet d’offrir aux développeurs une meilleure flexibilité du noyau.

La tendance étant portée actuellement sur le déploiement d’OS légers, Windows 10 prévoit la

possibilité de moduler le noyau NT en vue d’une meilleure adaptation face aux besoins actuels. Ce

critère s’inscrit parfaitement dans l’optique d’automatisation de déploiement des infrastructures

constituées de nombreux OS légers reposants sur des socles de virtualisation.


[74]

3.3.3. Un schéma d’industrialisation moderne

Grâce à la démocratisation des outils DevOps il est désormais possible d’industrialiser les SI en

poussant l’automatisation à son paroxysme. Une infrastructure DevOps complète doit posséder de

nombreux outils :

- Un gestionnaire de configuration serveurs ;

- Un outil d’intégration continue ;

- Un outil de supervision ;

- Un gestionnaire de versions ;

- Un outil d’analyse de performances ;

- Un outil de gestion des logs.

Figure 36 : Liste des outils DevOps

Face à la multiplication des solutions et au nombre de catégories d’outils à mettre en œuvre, il existe

de très nombreuses combinaisons possibles permettant de s’adapter à la plupart des typologies

d’infrastructures. Je me suis prêté à l’exercice par la conception d’une infrastructure DevOps

permettant d’automatiser au maximum toutes les composantes du SI tout en gardant la maitrise des

domaines de compétences de chaque partie. Ainsi les administrateurs systèmes possèdent toujours

le contrôle sur le déploiement et l’évolution des infrastructures, les développeurs ont la possibilité de

Outils DevOps

Gestionnaire de

configuration

Intégration continue

Supervision

Gestionnaire de versions

Analyse de la performance

Gestion des logs


[75]

déployer automatiquement le code dans les environnements prévus à cet effet et les exploitants

bénéficient de plusieurs outils de supervision et contrôle du SI déployés automatiquement sur

chaque nœud.

Docker

Serveur 1

OS1 OS2

Serveur 2 Serveur 3 Serveur 4

Hyperviseur VMWare

AP1 libs AP2 libs AP3 libs AP4 libs AP5 libs AP6 libs AP7 libs AP8 libs

OS3 OS4 OS5 OS6 OS7

C1 C2 C3 C4 C5 C6

Git

C7 C8

NAGIOS/Cacti

LogstashPuppet

GraphitePXE Manager

Eclipse

Figure 37 : Proposition d'une infrastructure équipée d'outil DevOps

Ce système permet d’initialiser en partie la gestion du système d’information. En effet, chaque partie

dispose d’outils permettant de supprimer en grande partie les opérations manuelles répétitives. Par

ailleurs, des processus d’enchainements sont mis en place afin de permettre l’enchainement des

processus en cascade automatisée. Ce système n’a absolument aucune prétention de perfection, il

démontre simplement un modèle envisageable de configuration pour une structure de grande

échelle.


[76]

3.4. La route vers l’industrialisation du SI par la synergie des procédés

3.4.1. Compatibilité des méthodes Agiles avec DevOps

Les méthodes Agiles sont un manifeste de bonnes pratiques de développement d’applications tandis

que DevOps est une culture, une idéologie. Ces deux procédés sont donc pleinement compatibles et

DevOps se veut être un prolongement évolutif des méthodes Agiles.

Il est très rare de trouver des entreprises qui ont intégré les principes DevOps sans être

préalablement formées sur les pratiques Agiles. DevOps perdrait ainsi beaucoup de son intérêt car ce

dernièr ne peut fonctionner en simple autonomie. DevOps serait beaucoup trop incomplet et

inadapté. Ainsi, DevOps peut s’agencer avec la plupart des méthodes reconnues Agiles (XP, RAP,

FDD, DSDM, Scrum, …).

DevOps a pour principal avantage d’intégrer la prise en compte des opérationnels. Jusque-là les

méthodes traitaient uniquement de développement. Bien sûr Agile intègre des notions de

collaborations interservices. Toutefois ces dernières se portent sur la coopération métiers-

développeurs ou sur la relation client-chef de projets. L’ajout des opérationnels et des autres

intervenants permet désormais de disposer d’une vision globale sur les projets IT qui est beaucoup

moins restrictive et donc plus pertinente à l’échelle d’une organisation.

Par ailleurs, DevOps optimise encore plus les pratiques Agiles au travers de ses valeurs. Il encourage

la DSI à progresser dans son ensemble par ses valeurs de transparence, de bons comportements,

anti-blâmes, de confiance et d’honnêteté.

3.4.2. Combinaison des méthodes Agiles, Scrum et de DevOps

Scrum est une façon de piloter des projets de développements IT issus d’Agile. Cette méthode est

également dite reconnue Agile car elle respecte scrupuleusement les principes fondamentaux et

valeurs de la méthode.

Concrètement, Scrum apporte de nouveaux principes. Notamment la réduction des temps de phase

de développement par un jalonnage fréquent des livraisons. Scrum préconise de livrer un logiciel

fonctionnel aux clients au maximum tous les quinze jours. Cette innovation permet d’améliorer

considérablement la façon de conduire des projets IT puisqu’elle se rapproche au plus près des

besoins des utilisateurs finaux. Cette idée est née d’après le constat qu’il existe une différence


[77]

marquante entre ce qu’imagine le client et ce que comprend l’équipe de développement. De plus,

cela permet d’éviter de perdre trop de temps de développement à reconstruire les applications en

cas de mécontentement du client.

Ce jalonnage intensifié induit également de repenser la façon de travailler. Les phases de

développement se déroulent désormais en courtes sessions. L’utilisation d’un tableau blanc permet

de répartir visuellement et facilement les tâches tout en suivant leur état d’avancement.

Par ailleurs, les sprints de développement entrainent un maintien de la productivité. Selon des

études, les développeurs attendent le dernier moment pour être productif. Le nombre de fonctions

produites par jour commence doucement lors du début du projet et augmente exponentiellement à

l’approche de la date de fin. Le respect du temps imparti impacte alors directement la qualité finale

de l’application. Avec des cycles de développement courts, la productivité peut donc être préservée

durant toute la durée du projet.

Pour résumer, Scrum constitue une modernisation d’Agile, plus en phase avec le contexte

économique actuel. Les enjeux concernant la productivité permettent de retirer un avantage

concurrentiel certain. Scrum permet de remplir ces critères.

3.4.3. Combinaison d’Agile, Scrum, DevOps et « Continuous Delivery »

Le continuous delivery apporte le chainon manquant pour automatiser et donc industrialiser le SI.

Chaque procédé a désormais sa place dans ce système d’industrialisation de par leur nature et leur

rôle unique.

Figure 38 : Combinaison Agile + DevOps + Scrum + CD

Agile

•Méthode de développement

DevOps

•Culture informatique

Scrum

•Gestion de projets de développement

Continuous delivery

•Approche de développement et d'automatisation

Combinaison des procédés


[78]

Les valeurs se rejoignent et sont complémentaires. Elles ont le même objectif commun : dynamiser

et améliorer la production du SI. L’accumulation des procéder rend le changement plus difficile à

conduire. De plus, cela complexifie la tâche des manageurs au quotidien en leur demandant

beaucoup de rigueur dans leurs faits et les actes. Cependant, il est désormais possible de ne

conserver que les points positifs de chacune des méthodes en éliminant les points de contradiction

par rapport aux objectifs de l’organisation.

Agile

Scrum

DevOps

Continuous Delivery

Productivité

Productivité de développement

Collaborationinterservices

Automatisation du développement, des tests et

des déploiements

Amélioration desprocessus internes

Figure 39 : Amélioration de la productivité

Dans une certaine mesure, si l’on considère que l’industrialisation consiste à atteindre une

productivité maximum, l’objectif peut être considéré comme atteint grâce à ces quatre procédés et

aux outils DevOps. Cependant il est toujours possible d’améliorer l’existant par de nouvelles

innovations. Nous pouvons ainsi imaginer pousser l’automatisation encore plus loin et amoindrir les

opérations manuelles afin de s’orienter vers un système de plus en plus robotisé.


[79]

Procédé Agile DevOps Scrum Continuous Delivery

Synthèse Typologie Méthode IT Culture IT Gestion de projet IT Approche de développement IT

Valeurs Prioriser la satisfaction cliente

Prioriser la satisfaction cliente

Prioriser la satisfaction cliente

Encourager le changement Encourager le changement Encourager le changement

Livrer régulièrement les applications

Assurer un minimum de production application régulière

Délivrer des nouveautés constamment

Discordance des principes

Inciter la collaboration métier-développeurs

Inciter la collaboration développeurs-opérationnels

Collaborer

Favoriser le dialogue face à face

Favoriser l'échange direct et interactif

Favoriser l'échange interactif

Comptabiliser seulement les fonctions opérationnelles

Comptabiliser seulement les fonctions opérationnelles

Promouvoir un rythme de développement soutenable

Promouvoir un rythme de livraison soutenu



Assurer la qualité de développement

Assurer la qualité de développement

Favoriser la simplicité

Favoriser la simplicité


[80]

Organiser les équipes en cellules autonomes

Responsabiliser les acteurs Responsabiliser les acteurs Responsabiliser les acteurs

Réfléchir sur les axes d'améliorations internes

Cultiver l'innovation Cultiver l'innovation Chercher à s'améliorer, à innover

Œuvrer pour la transparence



Encourager les bons comportements

Respecter tous les acteurs Encourager les bons comportements

Ne pas blâmer autrui

Faire preuve d'humilité Faire preuve d'humilité

Ne pas craindre l'échec

Ne pas craindre l'échec Ne pas craindre l'échec

Faire confiance

Faire confiance

Favoriser l'honnêteté et l'ouverture d'esprit

Favoriser l'ouverture d'esprit

Favoriser l'honnêteté et l'ouverture d'esprit

Améliorer la concentration des développeurs

Améliorer la concentration des développeurs

Automatiser le déploiement

Automatiser le déploiement

Automatiser les tests Automatiser les tests

Figure 40 : Matrice de compatibilité et synergie des procédés


[81]

Conclusion

Les structures informatiques s'agrandissent en même temps que les pratiques informatiques

évoluent. Cependant les entreprises n'embrassent pas réellement les innovations achevées

en matière de gestion de projets, ce qui induit un décalage grandissant entre les besoins et

les solutions mises en œuvre. Le constat logique était que les organisations IT internes se

contentent d'un système d'information fonctionnel et de procédures incomplètes pour

assurer la production mais elles sous estiment les apports des nouvelles pratiques. La

plupart des structures n'arrivent pas à se projeter suffisamment loin dans le temps pour en

dégager une vision suffisamment claire et pour percevoir la totalité des possibilités s'offrant

à eux grâce à ces nouvelles méthodes. Ce mémoire avait pour but premier de démontrer que

les efforts de réalisation du changement peuvent élever l'entreprise vers des sommets

auparavant impossibles à atteindre. L'objectif est de changer la vision des dirigeants et des

ingénieurs en démontrant que la mise en place de ces nouvelles méthodes de travail est,

certes difficile à mener mais, dérisoire par rapport aux enjeux.

Nous avons donc étudié les composantes de la culture DevOps, ses relations avec les

pratiques Agile et le « continuous delivery » puis concrétisé ces propos par les exemples de

Netflix et d'OVH. Nous avons ensuite étudié les structures des DSI de façon transverse en

abordant des thèmes tels que la performance d'équipe, les enjeux économiques, les

relations sociales et les théories de management applicables aux DSI qui sont à prendre en

compte en cas d'utilisation de ces nouvelles pratiques IT. Enfin, nous avons terminé ce

mémoire par un prolongement synthétique des deux parties précédentes pour apporter une

vision sur les possibilités d'industrialisation des SI. Pour cela nous avons intégré des concepts

de développement de la culture DevOps puis de conduite du changement. Nous avons

ensuite terminé par la gestion des outils DevOps et les combinaisons de méthodes

envisageables pour arriver jusqu'à un niveau d'automatisation élevé, proche d'une

industrialisation.

Selon moi, les pratiques et les outils actuels ne permettent pas d'atteindre une réelle

industrialisation de toute la chaine de vie d'un SI ou d'une application. Mais ils permettent

néanmoins de s'en approcher pour performer sur son marché et atteindre l'excellence par


[82]

une franche amélioration de la productivité sans perte de qualité. Je ne me vois pas comme

un prêcheur de l'utopie DevOps car j'estime que chaque organisation doit avoir la liberté

d'avancer à sa propre vitesse. Cependant si ma hiérarchie me demandait d'améliorer la

productivité au sein de la DSI, je m'orienterais immédiatement vers DevOps et ses outils car

je suis intimement convaincu que cette culture représente l'avenir de l'informatique, si ce

n'est le début d'une ère nouvelle. Je pense que mis à part les géants de l'informatique et une

poigné d'exceptions, le reste des sociétés mondiales souffrent cruellement d'un manque de

méthodologies et d'outils adaptés à la productivité. Le savoir-faire accumulé dans le

domaine informatique et des nouvelles technologies ne reflète pas la réalité terrain des

entreprises.

Ce mémoire peut également nous inciter à s’interroger sur l’avenir des métiers

d’administrateur systèmes et de développeur. Les deux domaines possèdent des

compétences spécifiques nécessitant de l’expertise, ce qui induit qu’ils ne pourront

disparaitre à court ou moyen terme. Cependant le changement apporté par DevOps agit

directement sur les missions des deux parties les recentrant sur de la création d’applications

ou d’infrastructures pure par l’automatisation qui supprime de nombreuses tâches réalisées

autrefois manuellement. Peut-on alors en déduire qu’à l’avenir ces professions tendront à se

restreindre considérablement jusqu’à provoquer une situation de crise ?

Sitographie

Liens internet – Partie 1 et 3 http://www.claranet.fr/propos-de/devops-et-int%C3%A9gration-continue.html

http://en.wikipedia.org/wiki/DevOps

http://www.google.fr/trends/explore#q=devops&date=1%2F2009%2071m&cmpt=date&tz=

http://blog.octo.com/et-si-devops-nous-emmenait-vers-tdi-test-driven-infrastructure/

http://www.devopsdays.org/presentations/

http://www.zdnet.fr/actualites/connaissez-vous-devops-le-cha-non-agile-manquant-39801743.htm

http://www.kolibricoaching.com/le-changement/changement-zone-de-confort-professionnelle/

http://www.semaweb.fr/101-prestations/271-la-methode-agile

http://www.esker.fr/esker_advantage/agile_methodology.asp

http://blog.valtech.fr/2010/08/30/rad-et-agilite/

http://www.zdnet.fr/actualites/les-quatre-principes-cles-de-la-methode-scrum-toujours-insuffisamment-suivis-39811719.htm

https://sethvargo.com/the-ten-myths-of-devops/

http://www.claranet.fr/propos-de/devops-et-int%C3%A9gration-continue.html

http://www.journaldunet.com/developpeur/algo-methodes/devops.shtml

http://www.cloudmagazine.fr/avis-expert/les-nouvelles-technologies-au-service-des-entreprises

http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html

https://www.numergy.com/developpeurs-blog/le-devops-dans-le-cloud-de-liac-aux-serveurs-jetables/

http://www.infoq.com/fr/news/2013/06/netflix

http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey

http://techblog.netflix.com/2011/07/netflix-simian-army.html

http://www.lemondeinformatique.fr/actualites/lire-les-outils-lies-a-devops-peseront-2-3-md$-en-2015-60441.html

http://www.bogotobogo.com/DevOps/DevOps_Jenkins_Chef_Puppet_Graphite_Logstash.php

http://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

http://radar.oreilly.com/2015/02/what-is-devops-yet-again.html

http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/

https://www.ovh.com/fr/news/articles/a1766.point-vue-ovh-loi-renseignement

https://www.ovh.com/fr/a1075.devops-profil-pointu-poste-ovh

https://blog.profitbricks.com/51-best-devops-tools-for-devops-engineers/

http://developpementagile.com/posts/2013/september/chiffres-en-appui-aux-bonnes-pratiques-agiles

http://devops.fr/

http://devops.com/

http://www.devopscon.com/

http://pro.01net.com/editorial/621600/devops-les-3-concepts-fondamentaux/

http://www.pagerduty.com/blog/transitioning-to-devops/

http://lemarketeurfrancais.com/methode-smarter-objectifs/

http://www.strategiemarketingpme.com/strategies/creer-objectifs-s-m-r-t-formule-magique-en-marketing/

http://www.masanteausommet.com/bien-se-sentir/trucs-et-outils/smarter-pour-maintenir-ses-resolutions

http://www.adbdp.asso.fr/spip.php?article456

http://www.csu.edu.au/__data/assets/pdf_file/0006/949533/fisher-transition-curve-2012.pdf

http://www.businessballs.com/freepdfmaterials/fisher-transition-curve-2012bb.pdf

http://www.aubryconseil.com/post/Les-valeurs-de-Scrum

http://developpementagile.com/posts/2013/february/les-valeurs-de-xp-scrum-kanban-et-les-tiennes

http://girlzinweb.com/2014/07/02/synthese-masterclass-hello-scrum/

http://www.silicon.fr/carlos-goncalves-sgcib-en-2015-moitie-applications-sera-livree-en-continu-2-97571.html

Liens internet – Partie 2 http://www.mc2i.fr/Qu-est-ce-qu-une-DSI

http://dvau.praxeme.info/wp-content/uploads/2009/06/book-soa_ch12.pdf

http://www.processus-metier.fr/index.php?option=com_content&task=view&id=17&Itemid=17

http://www.it-expertise.com/relations-dsi-metiers-trouver-le-chemin-de-lefficacite/

http://www.psychologuedutravail.com/tag/pyramide-des-besoins-de-maslow/

http://semioscope.free.fr/article.php3?id_article=8

http://mip-ms.cnam.fr/servlet/com.univ.collaboratif.utils.LectureFichiergw?ID_FICHIER=1295877018119

http://fr.wikipedia.org/wiki/Pyramide_des_besoins

http://www.orea.ch/les_9_etats_emotionnels.html

https://corporatecoachgroup.com/blog/sphere-of-influence

http://fr.slideshare.net/sihearn/om-for-policy-influencing

Bibliographie et re fe rences

Références bibliographiques Titre Sous-titre Auteur Date de

publication

Next Gen DevOps Creating the DevOps Organisation Grant Smith 2014

Continuous Delivery and DevOps : A quickstart guide

Continuous delivery and DevOps explained

Paul Swartout

2012

Continuous Delivery and DevOps : A quickstart guide Second Edition

Delivery quality software regularly and painlessly by adopting DevOps and CD

Paul Swartout

2014

Linux Magazine n°178 Développement et administration sur systèmes open sources

Benjamin Zores

2015

Webinar

Thème Présentateur Date

Transforming organizational culture through DevOps and Paas RedHat

26 mai 2015

Interview

Thème et acteur Date

Interview de Stéphane PAPILLON, ingénieur système groupe Fiducial, sur les nouvelles technologies DevOps open source et sur l’intégration d’Ansible

13 mai 2015

Références aux cours dispensés à Sciences U

Référence Professeur Date

Management des organisations - Management d’équipes Niveau 2 P. NOGRET

2014- 2015

Méthodes de développement Agiles J. MICHEL

2013-2014

Lexique

ACME : point extrême d’une tension ou d’une situation, une apogée, un point culminant. C'est un

nom purement fictionnel issu originellement d'un dessin animé.

AMI : Amazon Machine Image. Il s'agit d'une application virtuelle qui consiste à créer et gérer des

machines virtuelles Amazon.

API : Application Programming Interface.

Builds : Il s'agit de la modification du code source d'un programme informatique dans un

gestionnaire de sources. Chaque modification incrémentera un nouveau numéro de version. Ce

numéro de version correspond à un build, c'est à dire une version d'un logiciel à une étape donnée

de son cycle de vie.

CD : Continuous Delivery. Approche informatique consistant à livrer régulièrement et rapidement des

applications.

Commutateur : communément appelé switch, un commutateur est un équipement réseau qui

permet d'interconnecter des appareils entre eux, tels que des ordinateurs, serveurs ou

périphériques.

CRM : Customer Relationship Management ou Gestion de la Relation Cliente en francais. C'est un

outil destiné à gérer les clients, les ventes et le suivi commercial d'une entreprise.

DSI : Direction des Systèmes d’Information.

EC2 : Amazon Elastic Compute Cloud. C'est un service proposé par Amazon permettant à des clients

de louer des serveurs virtuels.

ITIL : Information Technology Infrastructure Library. Tout comme Agile, ITIL est un ensemble

d'ouvrages destiné à améliorer les bonnes pratiques informatiques.

LB : Load Balancer ou répartiteur de charge en français. C'est un équipement réseau ou un serveur

destiné à répartir la charge d'utilisation d'un service entre plusieurs équipements.

Logs : Fichiers journaux capitalisant un historique des évènements d'un programme informatique.

MEP : Mise En Production. C'est l'étape qui consiste à diffuser un programme informatique sur un

support utilisé par des clients ou des utilisateurs.

NTIC : (Nouvelles) Technologies de l'Information de la communication

Open source : il s'agit d'une désignation d'une catégorie de programme informatique dans lequel le

code sources est à la disposition du public.

R&D : Recherche et Développement.

REST : Representational State Transfert. C'est un style d'architecture distribuée.

Routeur : Il s'agit d'un équipement réseau assurant l'acheminement des informations dans un réseau

informatique.

Sprint de développement : Intensification du rythme de développement en vue de respecter les

délais imposés.

Annexes

Annexe 1 : Liste détaillée des outils DevOps

Outil Description Catégorie Prix/Licences

Agile Manager Agile Manager est une suite complète développée par HP permettant de créer des liens entre les équipes, de mettre en place automatiquement des indicateurs de performance et de suivre les états d'avancement d'un projet

Solutions propriétaires DevOps

Sur devis

Ansible Ansible est un outil de développement continu permettant de déployer et gérer la configuraiton des applications

Outils d'intégration continue

Basic: $99 par mois ou $1000par an Entreprise : sur devis

Ant Ant est un outil en lignes de commandes permettant de gérer les processus Apache2 et d'automatiser les opérations répétitives de developpement


Gratuit

BCFG2 BCFG2 est un outil de gestion de serveurs permettant de déployer massivement des configurations

Gestionnaire de configuration serveur

Gratuit

Bluepill Bluepill est un outil de supervision permettant de controler des processus ou des groupes de processus

Outils de supervision Gratuit

Cacti Cacti est un outil de supervision permettant de réaliser des graphique depuis des sources de données


Capistrano Capistrano est un outil d'automatisation d'administration de serveurs permettant d'ordonnancer des scripts entre les différents nœuds


Gratuit

CFEngine CFEngine est un outil de management des configurations permettant d'automatiser des déploiements de configurations serveurs et de synchroniser des données entre des serveurs hétérogènes


Gratuit

Chef Chef est un outil de gestion de serveurs permettant de déployer automatiquement et massivement des configurations


FREE - 10,000 nœuds Subscription - $6/nœud/mois Enterprise - sur devis

Docker Docker est un outil d'intégration continue permettant de construire, d'intégrer et executer des applications sur des plateformes distribuées. Il automatise le déploiement dans des conteneurs logiciels


Sur devis

Fabric Fabric est un outil d'intégration continue permettant de déployer automatiquement et massivement des applications sur des systèmes Linux par SSh


Gratuit

Ganglia Ganglia est un outil de supervision permettant d'assurer le contrôle de clusters


Git Git est un gestionnaire de version permettant d'organiser et de gérer le versionning d'un logiciel


Gratuit

God God est un outil de supervision simple d'utilisation permettant de superviser le fonctionnement d'applications et de serveurs


Gradle Gradle est un outil d'intégration continue qui permet d'automatiser le construction, les tests et le déploiement d'applications


Gratuit

Graphite Graphite est un outil de supervision enregistrant automatiquement des mesures prédéfinies et générant des graphiques statistiques

Outil d'analyse de la performance

Gratuit

Graylog Graylog est un outil de centralisation de logs permettant de centraliser, stocker, chercher et analyser des logs depuis n'importe quelle source prédéfinie

Outil de gestion des logs

Gratuit

Icinga Icinga et Icinga2 sont des outils de supervision permettant de superviser tout type de ressources matérielles et de réaliser un reporting graphique ou mesuré


Gratuit

Iperf Iperf est un outil d'analyse de la performance permettant de mesure la performance des réseaux


Gratuit

Jenkins Jenkins est un outil open sources d'intégration continue permettant d'automatiser et superviser l'intégration de tâches répétitives


Gratuit

Kibana Kibana est un outil de gestion des logs permettant de stocker et agencer des logs collectés en vue d'une analyse ultérieure


Gratuit

Loggly Loggly est un outil de management des logs permettant de détecter rapidement des causes problématiques au bon fonctionnement d'un système


Gratuit en version lite Standard : $49 / mois Pro : $109 / mois Entreprise : sur devis

Logstach Logstash est un outil de gestion des logs permettant de collecter, parser et stocker les logs après utilisation


Gratuit

Maven Maven est un outil d'intégration continue complémentaire à Apache2 permettant de gérer et automatiser la production de logiciel JAVA et JEE


Gratuit

Mcollective Marionette Collective est un framework intégrable dans Puppet destiné à exécuter des tâches sur des groupes de serveurs


Sur devis

Microsoft Azure Microsoft Azure est une plateforme cloud permettant d'héberger des serveurs virtuels et de disposer de différents services tels que des workflow, des espaces de stockage, des synchronisations de données. Un ensemble d'API permet de faciliter l'accès à la plateforme


Sur devis

Monit Monit est un outil de supervision des systèmes Unix-like permettant de gérer les problèmes pouvant apparaitre lors du cycle de vie d'un serveur


Multihost SSH Wrapper

Multihost SSH Wrapper est un outil permettant d'exécuter simultanément une commande linux vers plusieurs systèmes hôtes


Gratuit

NAGIOS NAGIOS est l'un des outils de supervision les plus complet du marché, il permet de superviser toutes les ressources d'un SI

Outils de supervision Gratuit Entre 2$ et 1000$ en version pro

New Relic APM New Relic APM est un outil de supervision permettant de mettre en place la supervision des applications et des bases de données de façon automatique

Outils de supervision Lite : Gratuit Pro : $149/mois/hôte Enterprise : Sur devis

OpenShift Enterprise

OpenShift est une PaaS produit par RedHat permettant de déployer automatiquement des applications, établir des worklow et suivre visuellement les étapes d'avancement d'un projet de développement


Sur devis

Pager Duty Pager Duty est un outil d'aggrégation pour les outils de supervision systèmes permettant d'améliorer la visibilité globale sur le SI et de fournir des alertes planifiées

Outils de supervision Standard : $19 / mois / utilisateur Enterprise : $39 / mois / utilisateur

PaperTrail PaperTrail est un outil de gestion de logs permettant de centraliser, stocker et organiser la gestion des logs et fournit une interface web pour les consulter


$230 par mois pour 25GB/mois

Perforce Perforce est un outil de gestion de configuration et de version permettant d'organiser et archiver les modifications appliquées sur un developpement tout au long de son cycle de vie


$720/utilisateur en licence définitive

Puppet Puppet est un outil de management d'infrastructure permettant de superviser l'état d'un SI. Sa finalité est d'automatiser les livraisons logicielles sur des nœuds de serveurs


Gratuit jusqu'à 10 nœuds Environ $112 /nœud / an

RANCID Rancid est un outil de gestion et déploiement de configuration réseau permettant de déployer automatiquement et massivement des configurations. Il maintient un historique des changements effectués

Gestionnaire de configuration équipements réseaux

Gratuit

Runit Runit est un outil de supervision permettant de lancer des démons sur des plateformes Unix-like


SaltStack SaltStack est un outil de gestion de configurations serveurs permettant de déployer des infrastructures et de les manager


Sur devis

Sensu Sensu est un outil de supervision permettant de détecter les problèmes de fonctionnement de services ou démon

Outils de supervision $50 par mois ou $500 par an

Snorby Threat Stack

Snorby Threat Stack est un outil de supervision permettant d’organiser simplement le contrôle de points de sécurité


Splunk Splunk est un outil de collecte de logs permettant de faciliter l'accès aux informations


Sur devis

Squid Squid est un outil d'optimisation web permettant d'améliorer la performance des infrastructures web client-serveur


Gratuit

Subversion Subversion est un gestionnaire de version permettant d'organiser et de gérer le versionning d'un logiciel


Gratuit

Sumo Logic Sumo Logic est un outil de gestion de logs permettant de simplifier le stockage, la gestion et l'analyse des logs pour les administrateurs dans le cloud


Sur devis

Supervisor Supervisor est un outil de supervision visant à contrôler des processus systèmes sur des groupes de serveurs Linux


systemd Systemd est un outil alternatif au système V Linux permettant d'offrir une meilleure gestion des dépendances entre les services et d'optimiser leur fonctionnement


Takipi Takipi est un outil d'analyse des logs permettant d'identifier rapidement les informations relatives à l'apparition d'incidents systèmes et logiciels


Gratuit en version lite Pro : $69 / mois / serveur Enterprise : sur devis

Upstart Upstart est un outil de supervision et de gestion des démons linux permettant d'agir sur les tâches de démarrage et les processus courants des serveurs


Urban code Urban Code est une suite complète portée sur le développement d'applications, le déploiement continue, la gestion des configurations et le versionning. La suite est developpée par IBM


Sur devis

Vagrant Vagrant est un outil de gestion de configurations serveurs utilisé pour créer et configurer des environnements de développement virtuels


Gratuit

comment industrialiser lesloicmieral.fr/wp-content/uploads/2017/09/loïc... · ainsi autour des...

Documents