DEVOPS et DEVSECOPS, qu’est que ça mange en hiver?

J’ai cette volonté de démystifier ce que sont ces deux nouveaux paradigmes, le DevOps et le DevSecOps.

Pourquoi j’utilise ce terme, c’est parce qu’il s’agit d’une collection de pratiques, qui ne sont pas fixes et sans une méthodologie précise d’implémentation. C’est en partie la raison de son succès. Il s’agit d’implémenter les choses presque de façon insidieuse. Bref de le faire afin que cela devienne dans notre quotidien sans heurts apparents.

Pour nous chez Emyode, cela se traduit par une orientation des efforts qui couvrent trois aspects importants de la transformation numérique et ce que ces paradigmes proposent. Soit la dimension « gens ou personnes », la dimension processus et la dimension outillage ou « produits ». On parle aussi de « people, process and tools ».

Ce que n’est pas le DevOps

J’aimerais donc commencer à adresser un point très important. On ne dit pas d’un individu qu’il est un DevOPS. Certes, il existe des gens qui travaillent bien assis entre l’exploitation opérationnelle (OPS) et les équipes de réalisation (DEV). Mais DEVOPS tout comme DEVSECOPS a la volonté de s’intégrer dans les équipes et non de créer de nouvelles subdivisions. C’est un job bien sexy, ne vous trompez pas. De faire de l’automatisation, du « Scripting » et de la maintenance d’infrastructure via du code est certes fort utile. Mais ce n’est qu’un maillon de plus dans notre chaîne de valeurs.

Ne vous fiez pas à moi, cherchez plutôt les définitions larges du terme et vous verrez que le point en commun de toutes ces définitions, c’est de détruire les silos opérationnels et fonctionnels et non d’en créer un nouveau.

En effet un des grands principes est celui de répartir les intérêts communs. Plutôt que de balancer le travail réalisé dans les mains d’une personne non-informée du processus de création, il est préférable d’avoir quelqu’un qui connaît le produit et son processus de fabrication. Cela fait de cet individu une personne bien plus efficace à accueillir le travail complété de son collègue et de le supporter plus adéquatement.

« Avec un spécialiste tel que ci-haut mentionné, on risque de devenir dépendant
de ses compétences et dans les faits de lui avoir remis les clefs de notre royaume.
Créant ainsi un point de défaillance unique (single point of Failure),
qui je vous assure est indésirable. Cela représente une antithèse
du mouvement DevOps et, de plus, celui du DevSecOps. »

Jean-Paul Lizotte, Chef de pratique DevOps chez Emyode

Les Personnes

Vous pourriez vous imaginer l’industrialisation d’un processus. Mais tout comme on le mentionnait plus haut, il sera important de considérer la dimension humaine de ce changement. Si on veut que cela perdure on doit tout d’abord avoir des gens qui ont une certaine conviction des valeurs que ce mouvement va apporter.

Il s’agit bien d’une transformation numérique. Les gens, quoi qu’on en dise, seront nantis de nouveau processus et de mesures objectives pour analyser les gains de performance. Soyez sûrs : il ne s’agit pas d’apporter l’analyse microscopique du travail, mais de pouvoir dériver les gains survenus lors d’implémentations, des bonnes idées ou initiatives. Mais on y reviendra.

Les Processus

Comprenons-nous bien. Les processus, sont au service des gens qui les emploient. Et non l’inverse. Oui, ils sont en place pour encourager le bon usage du reste (les outils), mais reste qu’on veut que les processus soient adaptés aux besoins de nos gens. Comme mon gestionnaire de programme favori le dit si bien : « Les processus existent et seront abusés par les utilisateurs, mais on ne doit pas avoir des processus qui abusent de nos gens. » Et dans l’idée il a parfaitement raison. Sinon, les personnes trouveront un moyen d’arriver à leur fins de n’importe quelle manière. Et au diable iront les processus.

Les Outils

Sans vouloir paraître bête, en technologie, il est trop facile d’avoir en sa possession un marteau lorsqu’on a besoin d’avoir un tournevis. Faire des choix judicieux en termes de sélection d’outils est souvent mieux digéré par les utilisateurs que les technologues. Donc, il va de soi, que ceux qui industrialiseront les processus doivent passer par un choix qui est orienté sur les besoins, plutôt que pour l’enthousiasme du dernier cri et d’être à la fine pointe de la technologie. Non, on va plutôt considérer la maintenance et le bon usage des outils en premier. Sinon on risque d’avoir un désajustement entre l’usage et le coût d’acquisition, sinon celui d’opération de ces outils.

DevOps et DevSecOps, à quoi ça sert?

Finalement, il est important d’avoir une idée du pourquoi ces mouvements sont nécessaires et ce qu’il n’est pas. Voyons ce que ces paradigmes tentent d’adresser.

Dans notre série courante, nous allons regarder certains enjeux et des pistes de solutions.

Je tenterai de les mettre dans les différentes dimensions, soit personnes, processus ou outils. Mais pour tout vous dire, je ne suis pas très friand de passer beaucoup de temps sur les outils. La vérité est que dès que nous avons des gens bien concentrés sur les bonnes activités, les moyens et la gouvernance de mettre ces choses-là en place, la sélection des outils devient presque naturelle. De plus, c’est là ou ça bouge le plus. Ce qui est vrai technologiquement parlant, ne l’est pas toujours la semaine suivante. Mais je vais tenter de l’illustrer.

Donc, des deux paradigmes DevOPS et SecDevOPS (qui est synonyme pour DevSecOps), on n’arrive toujours pas à s’entendre sur le nom.

Ce que les deux ont en commun c’est tout d’abord le désir de fusionner les préoccupations typiques de chacun des départements (développement-sécurité-opérations/ou développement-opérations). Comme on l’expliquait plus haut, le rapprochement de ces silos traditionnels opératoires a des conséquences bénéfiques.

Chez Emyode on dit « plus de projets, plus vite et plus d’économies ». Ce slogan est propulsé par le DevOps. Les valeurs ajoutées aux réalisations en plus de leur fluidité, sont la réduction des risques, des coûts. Mais aussi l’augmentation du niveau de satisfaction général (client et employé), la vélocité et la qualité du produit. Certes, cela ne nous tombe pas tout cuit dans le bec. Mais il s’agit du but, de la destination et non du moyen de s’y rendre. Finalement, sur ce sujet spécifique, on ne peut avoir qualité sans sécurité c’est pourquoi je n’aime pas parler du DevOps seul.

Mais pour être parfaitement honnête, on est très en retard sur ce front en tant que peuple industrialisé. En Europe et même dans les autres régions de l’Amérique du nord quand on se compare, on est tard à adopter cette façon de faire. Donc je dois atténuer la façon dont je pousse ces principes, au risque de perdre l’intérêt de mon auditoire. Je trouve important de mentionner que ce n’est pas faute de compréhension de ces derniers. Mais celui de peur de se faire ensevelir par la taille de la tâche herculéenne de se transformer. Laisser moi vous rassurer dans les deux cas, il n’en est rien. Dans mon dernier blogue je vous parle de rendre cette opérationnalisation digeste pour atténuer le risque mais d’aller quand même en avant.

Il faut avoir une approche un peu étapiste, un peu cyclique et un peu de vision.

On dit « à pas de bébé » ou baby steps dans notre jargon.

À suivre…

Dans nos prochains articles, je vous propose de faire la distinction entre DevOps et SecDevOPS et ce qu’ils tentent d’adresser en commun. Nous verrons des grandes étapes d’une « feuille de route » éventuelle. Le guide ou GPS de notre démarche pour implémenter un DevOps/SecDevOps avec succès.

La suite au prochain épisode !

JP