Dans une DSI, les équipes d’exploitation sont garantes de la stabilité et de l’intégrité du système, alors que les équipes de développement sont sollicitées pour des aménagements et des nouvelles fonctionnalités. Leurs objectifs sont source de discorde dont la principale victime est l’activité. Et j’emploie le terme d’activité pour l’activité commerciale de biens ou de services d’une entreprise, pour l’activité morale, sociale, éducative d’une association, pour l’activité politique d’un parti, ou pour tout autre forme d’activité parce que la finalité de l’outil informatique est bien de porter une activité.

Cette activité demande de pouvoir, d’une part exprimer un besoin, soit une entrée pour le développement et d’autre part utiliser son système d’informations dans de parfaites conditions soit une sortie pour l’exploitation. Les plus acerbes diraient que le serpent se mord la queue. Et les querelles de clocher.
Pour le bien de l’activité, le mouvement DevOps promeut la suppression de ce point de friction par le rapprochement entre les équipes. Et pour ce faire, le mouvement DevOps réfléchit, explore et propose de nouvelles organisations, de nouvelles méthodes en privilégiant la motivation de chacun et la coopération de tous.

Le mot DevOps est la contraction des mots anglais Development et Operations (faux ami pour exploitation), le mot est inventé par Patrick Debois en octobre 2009. Au travers de cette contraction on perçoit le rapprochement entre les équipes.
L’erreur commune dans l’imagination collective est de comprendre cette contraction comme la périphrase « développements au bénéfice de l’exploitation ». Certes ils existeront mais ce n’est pas cet aspect qui est souligné ; Il faut comprendre le néologisme DevOps comme une fusion des équipes de développement et d’exploitation.

Comme tout rapprochement dont l’objectif est la pleine coopération, la démarche commence par une consultation, par des échanges. Confrontations d’expérience, de contraintes, d’exigences, voire de rites, d’us et coutumes. Bien avant la question des outils à utiliser, il faut se poser celle des femmes et des hommes qui vont collaborer. J’insiste sur ce facteur humain parce qu’il n’est ni quantifiable ni qualifiable. Un des piliers du mouvement DevOps est -j’ose- le « bonheur de produire de la qualité ensemble ».

Rapprochement, certes, mais concrètement qu’en est-il ?

Prenons en exemple une situation assez classique somme toute, et sans grande teneur technique.
Un programme informatique peut produire un historique de son exécution. Un journal des actions effectuées et de notifications diverses.
C’est le développeur qui conditionnera le programme pour qu’il écrive ceci ou cela dans son historique. Et pour ses propres besoins le développeur choisira que le programme note quelle fonction ou sous-routine sont appelées, quelques valeurs de variables techniques pour contrôler la cohérence des algorithmes. Bref, tout un tas d’informations internes au code.

Et c’est une telle définition de remplissage d’historique qui pourrait être exploitée. Alors que de son côté l’exploitant n’en a cure ! En effet, l’exploitant de son côté n’est pas en charge du fonctionnement interne du programme, mais de son fonctionnement en interaction dans un contexte, on pourrait dire son fonctionnement externe. Pour l’exploitant ce que l’historique devrait contenir c’est le fichier en cours de traitement, le produit, le client, la facture, et autre item en cours de traitement. Bref, tout un tas d’informations externes qui permettent à l’exploitant de connaitre la situation et répondre à la question « où en est le traitement informatique ? ».

L’un (le développeur) produit des traces qui d’une part ne servent pas à l’autre (l’exploitant), mais d’autre part ne lui proposent pas les informations qui lui siéent.
Le constat est simple et l’attitude DevOps est la collaboration. Un atelier permet à l’exploitant d’exprimer son besoin, de le définir, auprès du développeur. Et le développeur codera les notifications nécessaires à une exploitation en bonne et due forme.

On touche ici du doigt un des aspects importants qui est le retour d’informations. Nous ne sommes plus dans un besoin du métier qui dégouline dans un sens unique vers l’exploitation. Nous ajoutons de facto, un sens retour qui permet d’aménager pour plus de stabilité, de fiabilité. Qui mieux que l’exploitation peut s’enquérir de ce souci et exprimer les améliorations nécessaires ?

Et donc pas d’outils ?

Si les outils ont pleinement leur place dans une démarche DevOps, mais s’ils sont des moyens ce ne sont pas des finalités. Et ce n’est pas parce qu’on a installé un logiciel estampillé DevOps, qu’on est dans le mouvement ! A l’instar du traitement de texte qui ne fait pas l’écrivain.

Au lieu de produire une liste à la Prévert d’une exhaustivité décroissante avec le temps des outils, je vais décrire les différentes approches… dans le prochain article (un bébé est une boule de bonheur qui pompe son biberon et le temps de ses parents).