DevOps en action, les réalités du terrain

« C’est terminé le déploiement d’un logiciel lourd avec des upgrades tous les ans, place à l’agilité et au développement continu grâce au Devops tout en réduisant la chaine intermédiaire », lance Sylvain Siou, director systems engineering EMEA chez Nutanix. A en croire le deuxième baromètre DevOps en France réalisé par IDC (en partenariat avec Automic Software, Avanade et Serena Software) en septembre 2016, la tendance du Devops est bien là. Ainsi, 29 % des entreprises avaient formellement intégré DevOps dans leurs processus en 2016 contre 25 % en 2015, soit une progression de +15 % sur un an. IDC estime même que 46 % des entreprises françaises sont déjà fortement sensibilisées à l'approche DevOps. Sur le terrain, lors de nos différentes matinées débats auprès de décideurs IT, qui se déroulent dans 8 grandes villes, notre rédaction a pu constater cet engouement autour du DevOps notamment pour les nouveaux projets. Il faut dire que les deux premiers bénéfices du Devops, à savoir le délai de mise en œuvre sur le marché (Time to Market) des applications et des environnements auprès des métiers et de leurs clients puis l’amélioration de la qualité des développements applicatifs séduisent les entreprises dans un contexte ou l’ubérisation menace des pans entiers de nos industries.

Plusieurs grands groupes français se sont déjà engagés dans le DevOps à l’instar de la Société Générale. La banque a, par exemple, décidé dès 2013 d’évoluer vers ce concept en utilisant, dans un premier temps, différents services d’automatisation (solutions d’automatisation de HPE à l’époque dont Cloud Service Automation) pour gérer le cycle de vie de plusieurs centaines d’applications en production et pour aider ses développeurs à livrer plus rapidement des applications en passant de quelques jours à quelques heures dans des environnements standards ou dans le Cloud. Comment ? En diminuant les tâches répétitives, en réduisant le temps de provisionnement, en diminuant le nombre de releases. En parallèle, le groupe bancaire a aussi gagné en agilité et en fiabilité.

D’abord une démarche organisationnelle

Depuis, la banque poursuit sa démarche DevOps. A ce titre, lors de la conférence Devops REX organisée le 28 novembre dernier à Paris, deux coachs DevOps Adrien Blind et Laurent Dussault de la Société Générale ont expliqué comment ils avaient, depuis 3 ans, engagé leur rapprochement entre les équipes (opérationnelles, métiers et développeurs) et distiller des nouvelles pratiques en prenant en compte l’existant. De même pour le géant de l’assurance Axa qui a mis en place des features teams au sein de la DSI, ce qui a permis de créer une proximité entre les équipes métiers et l’IT pour proposer des solutions adaptées aux besoins des clients. Le rapprochement des équipes n’est pas forcément un exercice facile mais Axa a développé, dès 2015, une approche ludique en faisant participer ses équipes à des ateliers. Par exemple, construire un robot (Lego Mindstorm) et développer un logiciel pour qu’il trouve seul son chemin dans un labyrinthe. Dans un premier temps, Axa a donc positionné les développeurs (devs) d’un côté, et les opérationnels (ops) de l’autre, sans communication physique pour des résultats non concluants (robots immobiles ou mauvaise trajectoire du robot).

Dans un second temps, Axa a mélangé les devs et les ops et là, les résultats étaient plutôt positifs avec une véritable collaboration entre les équipes et des tests concluants sur les robots, une équipe a même atteint son objectif. Dans l’exemple d’Axa, nous pouvons percevoir l’importance de la formation à l’initiative DevOps auprès de tous les collaborateurs de l’entreprise afin d’éviter prioritairement aux équipes de continuer à fonctionner sur un modèle cloisonné. Pour Jean-Louis Lormeau, digital performance architect chez Dynatrace, ne pas prendre la peine d'éduquer et de former tout le monde aux processus et aux technologies cross-fonctionnelles, c'est vouer la démarche DevOps à un échec certain. « Les changements humains restent les principaux freins au développement de Devops qui réclame une nouvelle façon de travailler. Bref, le collaborateur n’est plus identifié à une case. L’infrastructure devient programmable, de ce fait, même les administrateurs systèmes évoluent avec de nouvelles compétences dans le scripting pour comprendre les développeurs. La valeur n’est plus dans la plomberie mais dans les couches plus hautes », conclut Sylvain Siou, director systems engineering EMEA chez Nutanix.  

NoOps... No Future... ?

L’imagination des cabinets d’études est sans limite à l’image de Forrester qui a inventé le terme de NoOps (No Operations). D’ailleurs, il faut remonter à 2011 pour entendre la première fois ce concept de NoOps par Forrester dont le but est d’automatiser complétement le déploiement, la surveillance et la gestion des applications et l'infrastructure sur laquelle elles fonctionnent. En clair, plus besoin d’équipes opérationnelles dans les entreprises, les développeurs suffisent et sont responsables du cycle de vie des applications et des environnements. En 2017, qu’en est-il concrètement du NoOps ? Pas grand-chose, car les entreprises n’ont tout simplement pas l’intention de confier les clés de la gestion de leur système d’information aux développeurs, même si en théorie avec le NoOps, l’automatisation se substitue aux opérationnels. De plus, pour l’heure, les développeurs n’ont pas les compétences à gérer des technologies souvent hétérogènes et complexes qui se trouvent dans les infrastructures. A chacun son métier, pourrait-on dire ! 

En soi, l’approche DevOps ne se résume ni à une infrastructure, ni à des règles précises. C’est d’abord une approche culturelle composée de bonnes pratiques, de méthodologies agiles, de collaboration entre les développeurs et les équipes opérationnelles et d’outillage qui permet au système d’information de répondre ou de s’aligner aux besoins des différents métiers dans des temps très courts. Bien sûr, l’outillage est stratégique dans cette approche DevOps. Et toutes les solutions qui simplifient la gestion et facilitent l’automatisation des processus - auparavant faite manuellement - rentrent dans ce concept de DevOps. Les microservices (généralisation des conteneurs de type Docker et des systèmes d’orchestration), la gestion des API, les outils d’intégration continue de type Jenkins, les langages de développement agiles, le cloud, sans oublier les plateformes de type PaaS qu’elles soient en open source ou propriétaires, représentent autant d’outils qui accélèrent le DevOps en entreprise. « Chez Nutanix, nous fournissons l’outillage pour aller vers cette approche Devops, cela se traduit par la création d’une plateforme pour déployer des VM et des conteneurs Docker avec un interfaçage simplifié et une automatisation. C’est dans cette optique, il y a six mois, que nous avons fait l’acquisition de Calm.io pour concevoir des applications en s’intégrant avec divers composants (Docker, Jenkins, etc.) », précise Sylvain Siou, director systems engineering EMEA chez Nutanix.

Un outillage très hétéroclite

En clair, le DevOps n’est donc pas lié à une marque ou une technologie. Prenons l’exemple du groupe bancaire Arkéa (groupe Crédit Mutuel) qui s’est appuyé, entre autres, sur la plateforme BlueMix Devops Services pour créer son premier projet Blockchain visant à vérifier l’identité de ses clients. De son côté, l'organisation agile DataFactory d’i-BP, filiale du groupe BPCE qui permet de repenser la gouvernance et les process de développement en décloisonnant les métiers, l'IT et l'exploitation se sont dotés d’outils d’origine Terradata (deux nouveaux Enterprise Data Warehouse et une plateforme de développement capacitaire) ; l’objectif étant de renforcer son dispositif autour de la donnée. Le groupe d’assurance Swiss Life France, quant à lui dans sa démarche Devops, a fait le choix de solutions open source comme Jenkins mais aussi commerciales comme la solution d’automatisation de la mise en production Release Automation de CA Technologies. A ce titre, le cabinet Gartner estime que les outils ARA (Application Release Automation) jouent un rôle prioritaire dans le Devops. Déjà, ces solutions permettent de créer des modèles d’application pour chaque environnement avec des paramètres de configuration externalisés. De plus, ils réduisent le niveau d’erreur humaine dans les scripts en fournissant un ensemble de tâches d’automatisation qui remplace ou supplante les scripts manuels.

Une mise en production accélérée

Autre exemple, celui du géant aéronautique Airbus qui, dans son approche open source (OpenWay of Working), a choisi la plateforme Red Hat OpenShift (interopérable avec les conteneurs Docker et le gestionnaire de cluster Kubernetes entre autres) en y associant le Devops. Avec cette démarche et son outillage, le groupe aéronautique a créé et mis en production, en seulement trois mois, l’application ITOp, un ERP dédié à toute la gestion des assets de son infrastructure (serveurs, back office, connectivité, etc.). Airbus a également créé un portail dédié aux utilisateurs finaux qui regroupe tous les outils liés au support IT permettant de gérer les demandes et les incidents. Grâce au DevOps, ce portail était opérationnel en deux mois pour 400 utilisateurs puis accessible à 100 000 utilisateurs après les trois mois suivants. Pour Airbus, sans DevOps, il est impossible d’arriver à de tels délais de mise en production.

Bien sûr, l’agilité des outils de développement est indispensable mais, en parallèle, l’entreprise ne doit pas négliger la gouvernance d’une démarche Devops afin de garantir dans le temps de disposer d’équipes engagées et coordonnées. Là aussi, des solutions techniques existent, les APM (Application Performance Management) qui non seulement permettent de mesurer le fonctionnement des systèmes et des applications, mais servent également de passerelle de communication entre les différents services de l’entreprise. En effet, via une application APM, il est désormais possible d’échanger, de partager la compréhension globale du fonctionnement du système entre toutes les équipes, et ce, jusqu’à la requête SQL.

Du code à minima pour la création d'applications métiers

L’éditeur français Anakeen propose aux DSI, Anakeen Platform, une solution (en mode SaaS ou en mode on premise) dite low-code de création d’applications métier complexes. L’objectif est de permettre aux décideurs IT d’accélérer la mise en production d’applications et d'accompagner plus simplement les métiers vers les nouveaux usages. Techniquement, Anakeen Platform ne nécessite d’écrire que très peu de code (20 fois moins de lignes de code par rapport à un framework) car cette plateforme génère automatiquement tous les composants (structuration des données, moteur de workflow, droits dynamiques, interfaces graphiques responsives et ergonomiques). Selon Mickaël Kwasnik, directeur commercial et marketing d'Anakeen, plus de 100 000 personnes l’utiliseraient déjà quotidiennement. A ce titre, l’éditeur aurait déjà conquis plusieurs grands comptes dont plusieurs ministères (Outre-Mer, la Défense, l’Intérieur) mais aussi Veolia Water, le Hcéres, le CNES, l'AFNOR, etc.

Pouvez-vous nous présenter Ineat Group et comment vous vous positionnez par rapport au Devops ?

Ineat Group, qui compte 200 salariés, accompagne ses clients dans leur transformation digitale. De par notre présence à Lille, 60 % de nos clients travaillent dans le secteur du retail comme Leroy Merlin, Auchan, Décathlon, etc. Récemment, Ineat Group a reçu le Pass French Tech nous plaçant comme la première société numérique des Hauts-de-France à revendiquer ce label, en quelque sorte un gage qui nous permet d’accélérer notre développement sur le territoire national et international. Chez Ineat, aujourd’hui, tous les nouveaux projets de nos clients s’inscrivent dans une démarche Devops. Et ce sont donc les développeurs qui exécutent les actions de mise en production.

Comment a débuté cette démarche Devops ?

Nous avons débuté, dès 2014-2015, chez nos clients par des ateliers (workshops) d’accompagnement et d’explications. Aujourd’hui, nous arrivons en renfort de moyens sur des chaînes d’industrialisation (propres à chaque projet) avec les développeurs en prise directe avec les métiers. Chez Ineat, nous parlons même de MetDev (Métier & Développement). Même les administrateurs systèmes devront avoir cette compétence développement, leur recrutement est même conditionné à ce qu’ils soient aussi des experts du scripting. Car nous considérons que la prise de pouvoir est aujourd’hui au responsable de l’application, au chef de projet.

Quelle est l’importance de l’outillage dans une approche Devops ?

Une démarche Devops se partage entre la technique (50 %) et la méthode (50 %). Nous concernant, chez Ineat, nous utilisons essentiellement des solutions du monde libre qui amènent rapidement du ROI comme les outils Docker, Rancher, Jenkins, Puppet, etc. N’oublions pas que le Devops doit nous faire gagner du temps, diviser le temps par trois ou quatre implique une forte industrialisation, ce que permettent tous ces outils.

Quels sont les freins au Devops ?

Le principal frein à la démarche Devops est l’organisation interne. Ce qui explique que le Devops cible les startups et les grandes entreprises qui ont su construire une organisation interne très agile pour la réalisation de leurs nouveaux projets. En aucun cas, le Devops est adapté à un existant.

« La rapidité de développement, une disponibilité immédiate et continue puis le coût sont les trois éléments différenciant dans notre choix de la plateforme de déploiement en continu proposée par Platform.sh et hébergée chez Orange », souligne François Pottier, directeur technique chez Slate.fr. Rappelons que Slate.fr est un site d'informations, l'entreprise dispose aussi d'un autre site d'actualités dédié à l'Afrique francophone. Précisons que Slate.fr fête ses 8 ans et emploie environ 25 personnes. A l'origine, le site Slate.fr, développé sous Drupal, était géré par un autre hébergeur mais pour des raisons économiques et de faisabilité technique, l'entreprise spécialisée dans les médias a décidé de changer de prestataire. « Nous étions en désaccord sur plusieurs points avec notre ancien hébergeur. Et par rapport aux services rendus par notre prestataire, nous estimions payer trop cher. Nous souhaitions ainsi découvrir de nouveaux outils pour bénéficier de plus d'environnements de tests, mais aussi d’obtenir de ressources serveurs supplémentaires en temps réel en cas de surchauffe d’activité », indique François Pottier. Face à ces constats, Slate.fr recherchait donc un acteur capable de répondre à ses nouveaux besoins. Et en recherchant simplement sur Google, Slate.fr est tombé sur Platform.sh, les équipes ont rapidement été séduites par l'approche Devops du fournisseur. De plus, la proximité géographique avec Platform.sh a conforté le choix de Slate.fr.

Des créations d'environnements à la volée

« La création de plusieurs environnements de développement à la volée pour aller plus vite et le fait que les équipes de Platform.sh maîtrisant parfaitement Drupal sont très réactives en termes de support nous confortent dans notre choix », précise François Pottier. Pour Slate.fr, le gain de temps est réel, de l'ordre de 30 à 40 %, la mise en production est donc nettement plus rapide, nous confirme le directeur technique qui reconnaît aussi qu'il est plus simple de résoudre les problèmes avec son nouveau prestataire. Plusieurs projets ont été développés dans cette approche Devops avec Platform.sh, dont la mise en place d'une partie payante du site avec la sécurisation des données personnelles et la gestion des cartes de crédit et mots de passe (un projet pilote parfaitement mené mais qui n'a pas été retenu par Slate.fr pour des raisons stratégiques). Un autre projet est actuellement en cours (non communiqué par Slate.fr) et qui sortira d'ici la fin de l'année.

Entre autres bénéfices du Devops fourni par Platform.sh, Slate.fr apprécie l'anticipation de son prestataire. « En cas de surchauffe d’activité, par exemple pour la couverture de l’élection présidentielle, Platform.sh est capable de nous allouer immédiatement plus de ressources serveurs », admet François Pottier. Et d'ajouter : « Leur organisation Devops nous permet d'avoir également toujours les bons profils à tous les niveaux selon nos besoins ». Notons enfin que la migration vers Platform.sh, qui a débuté vers le 20 septembre dernier, a duré environ trois semaines.

Depuis 2014, le groupe Sanofi teste et exploite l’application CA Release Automation de CA Technologies pour automatiser le déploiement applicatif au sein de sa division Production. « Au cœur de notre service Production, nous comptabilisons environ 150 applications réparties suivant deux modèles, un modèle centralisé et un modèle de déploiement sur site », résume Christophe Galibert, expert technique pour Sanofi ITS Industriel. Et d’ajouter : « Notre objectif était donc de gagner du temps dans la mise en production des releases de nos applications en automatisant davantage et donc en diminuant les tâches manuelles notamment pour la production de documents, l’ensemble dans un environnement très réglementé et complexe ». En effet, toutes les tâches étaient réalisées manuellement avant 2014.

Fort de ce constat, les équipes de Sanofi sont parties à la recherche d’une solution permettant d’orchestrer des installations complexes et se sont donc orientées vers Nolio (entreprise israélienne rachetée depuis par CA Technologies) devenue CA Release Automation. Un pilote a rapidement été mis en place pour les deux modèles (centralisé et sur site). « L’idée du projet pilote était de valider la couverture technique. Ce pilote s’est déroulé sur toute l’année 2015. Il s’est révélé très concluant, ainsi sur l’application centralisée, nous sommes passés de 1 à 2 jours pour la mise en production d’une release à moins d’une heure. Concernant l’application sur site, nous sommes passés de 10 jours à moins d’une journée. En interne, des ressources partagées entre développeurs et opérationnels ont été affectées pour déployer le socle technique et les releases. Nous sommes donc clairement dans cette approche Devops dans le cadre de cette automatisation », indique Christophe Galibert.

Aujourd’hui, une dizaine d’applications est gérée avec CA Release Automation mais le but est d’étendre le déploiement automatisé vers de nouveaux Core Models. Bref, à terme de gérer presque la totalité du parc applicatif, dans la mesure du possible, hormis certaines applications métiers directement prises en charge par l’éditeur. Christophe Galibert avoue toutefois qu’il est difficile de mettre en place une organisation Devops de par leur environnement très réglementé. En effet, tous les laboratoires pharmaceutiques sont confrontés à des réglementations très contraignantes car ils doivent être en capacité de tracer tous les systèmes et outils utilisés dans le cadre de la production de médicaments. Cette contrainte règlementaire rend plus complexe la possibilité d’étendre les outils DevOps. Le cheminement se fait donc pas à pas, le service Production de Sanofi recherche avant tout la qualité et la fiabilité sur les différents sites, étant donné qu’il ne vise pas des releases quotidiennes comme le fait la Fnac avec son site de commerce en ligne par exemple.