Upload
others
View
8
Download
1
Embed Size (px)
Citation preview
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 8 : PROCESSUS DE DEVELOPPEMENTS ACME LOGICIELS - VERSION 2.0 ...................................................................... 10
FIGURE 9 : PROCESSUS DE DEVELOPPEMENTS ACME LOGICIELS - VERSION 3.0 ...................................................................... 11
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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement 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.)
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Figure 8 : Processus de développements ACME logiciels - version 2.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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[11]
Figure 9 : Processus de développements ACME logiciels - version 3.0
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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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).
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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é.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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)
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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,
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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 :
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[32]
Figure 15 : Concept de la Simian Army présentée par Netflix
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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 interne N2
Assistance interne N3
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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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é.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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é
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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,
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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"
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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 ?
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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é.
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Promouvoir un rythme de livraison soutenu
Promouvoir un rythme de livraison soutenu
Assurer la qualité de développement
Assurer la qualité de développement
Favoriser la simplicité
Favoriser la simplicité
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Œuvrer pour la transparence
Œ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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Comment industrialiser les systèmes d’information par le mouvement DevOps ?
[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
Outils d'intégration continue
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
Outils de supervision Gratuit
Capistrano Capistrano est un outil d'automatisation d'administration de serveurs permettant d'ordonnancer des scripts entre les différents nœuds
Gestionnaire de configuration serveur
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
Gestionnaire de configuration serveur
Gratuit
Chef Chef est un outil de gestion de serveurs permettant de déployer automatiquement et massivement des configurations
Gestionnaire de configuration serveur
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
Outils d'intégration continue
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
Outils d'intégration continue
Gratuit
Ganglia Ganglia est un outil de supervision permettant d'assurer le contrôle de clusters
Outils de supervision Gratuit
Git Git est un gestionnaire de version permettant d'organiser et de gérer le versionning d'un logiciel
Gestionnaire de versions
Gratuit
God God est un outil de supervision simple d'utilisation permettant de superviser le fonctionnement d'applications et de serveurs
Outils de supervision Gratuit
Gradle Gradle est un outil d'intégration continue qui permet d'automatiser le construction, les tests et le déploiement d'applications
Outils d'intégration continue
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é
Outil de gestion des logs
Gratuit
Iperf Iperf est un outil d'analyse de la performance permettant de mesure la performance des réseaux
Outil d'analyse de la performance
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
Outils d'intégration continue
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
Outil de gestion des logs
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
Outil de gestion des logs
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
Outil de gestion des logs
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
Outils d'intégration continue
Gratuit
Mcollective Marionette Collective est un framework intégrable dans Puppet destiné à exécuter des tâches sur des groupes de serveurs
Gestionnaire de configuration serveur
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
Solutions propriétaires DevOps
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
Outils de supervision Gratuit
Multihost SSH Wrapper
Multihost SSH Wrapper est un outil permettant d'exécuter simultanément une commande linux vers plusieurs systèmes hôtes
Gestionnaire de configuration serveur
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
Solutions propriétaires DevOps
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
Outil de gestion des logs
$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
Gestionnaire de versions
$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
Outils d'intégration continue
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
Outils de supervision Gratuit
SaltStack SaltStack est un outil de gestion de configurations serveurs permettant de déployer des infrastructures et de les manager
Gestionnaire de configuration serveur
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é
Outils de supervision Gratuit
Splunk Splunk est un outil de collecte de logs permettant de faciliter l'accès aux informations
Outil de gestion des logs
Sur devis
Squid Squid est un outil d'optimisation web permettant d'améliorer la performance des infrastructures web client-serveur
Outil d'analyse de la performance
Gratuit
Subversion Subversion est un gestionnaire de version permettant d'organiser et de gérer le versionning d'un logiciel
Gestionnaire de versions
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
Outil de gestion des logs
Sur devis
Supervisor Supervisor est un outil de supervision visant à contrôler des processus systèmes sur des groupes de serveurs Linux
Outils de supervision Gratuit
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
Outils de supervision Gratuit
Takipi Takipi est un outil d'analyse des logs permettant d'identifier rapidement les informations relatives à l'apparition d'incidents systèmes et logiciels
Outil de gestion des logs
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
Outils de supervision Gratuit
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
Solutions propriétaires DevOps
Sur devis
Vagrant Vagrant est un outil de gestion de configurations serveurs utilisé pour créer et configurer des environnements de développement virtuels
Gestionnaire de configuration serveur
Gratuit