« J’administre Jenkins dans ma boite, je suis DevOps. » Combien de fois ai-je entendu pareille billevesée ? Je ne sais pas, je ne compte plus !

Être DevOps, c’est tendance et nombreux sont les développeurs qui se targuent de l’être sans jamais avoir réellement fait l’effort de comprendre ce que recouvre ce terme. Ils ne savent pas que le mot DevOps ne décrit ni un poste, ni une panoplie d’outils, mais une culture. S’ils associent DevOps à l’agilité, ils ne savent pas vous expliquer ce que DevOps apporte aux cadres agiles antérieurs et à quel point DevOps est compatible avec eux. Or, la question se pose notamment pour le cadre Scrum, qui connait un succès croissant en entreprise et dont les fenêtres temporelles strictes s’accommodent à priori très mal du déploiement continu proné par le mouvement DevOps (je vous rassure, au prix de quelques ajustements, il est possible d’intégrer les pratiques DevOps dans un projet piloté en Scrum sans rendre la vélocité chaotique).

J’ai pour ma part un intérêt de longue date pour les cadres agiles et pour DevOps. J’ai suivi des formations consistantes et j’ai lu énormément à leur sujet. Je promeus des pratiques et je déploie des plateformes de développement collaboratif qui font la part belle à l’automatisation via le test, l’intégration continue, la livraison continue et le suivi qualimétrique. Je veille à la supervision des serveurs de production dont j’ai la charge et à la notification de toute anomalie susceptible d’affecter leur bon fonctionnement. Ce faisant, j’ai probablement une culture DevOps bien supérieure à celle de nombreux ingénieurs DevOps autoproclamés.

Pourtant, je ne me dis pas « ingénieur DevOps ». Mes pratiques sont loin du compte. Les équipes qui m’entourent (celles de mon entreprise, de nos clients, de nos partenaires et de leurs autres sous-traitants) n’ont en général ni conçu, ni implanté dans leurs solutions, les mécanismes permettant la mise en œuvre sereine de cette approche. Les tests automatisés ne sont pas assez couvrants ou probants. Le déploiement monolithique n’a rien de progressif ou de « blue-green » ; c’est déjà bien lorsqu’il est complètement automatisé.

Un recruteur me disait récemment « Nous n’allons pas faire de DevOps à court terme, mais nous souhaitons aller dans cette direction. Du coup, nous utilisons ce terme dans la description des postes que nous proposons. » Entre personnes qui prétendent s’y connaitre en DevOps et entreprises qui prétendent avoir besoin de cette compétence, sur un malentendu, il doit être possible de conclure. Mais je ne serais pas étonné de voir poindre d’ici quelques années de la défiance vis-à-vis de DevOps, comme on en voit déjà vis-à-vis de Scrum. Car à trop faire semblant et à ne pas embrasser pleinement la transformation, on finit par accumuler les inconvénients, voire par en créer, sans jamais bénéficier des avantages.