Nouveaux métiers de l'informatique ou alibis ?

Depuis le début de l'année, BPCE promeut le métier de « DevOps » au sein de ses équipes informatiques et le principe me fait a priori sursauter car il contient une contradiction. Certes, en creusant les détails, je pense comprendre le raisonnement sous-jacent… mais je reste convaincu qu'il risque d'être contre-productif. Et ce n'est pas le seul cas du genre.
Sans entrer dans les détails techniques, rappelons simplement que le concept de « DevOps » est apparu, dans le sillage des approches agiles, avec un objectif d'accroître la rapidité, la réactivité et la fiabilité des processus de déploiement en production des logiciels, par l'établissement d'un alignement, aussi direct, fluide et automatisé que possible, entre les étapes de développement et d'exploitation. Or il paraît surprenant de vouloir atteindre un tel objectif en introduisant un maillon supplémentaire dans la chaîne.
En effet, il ne faut pas être grand clerc pour réaliser que la mission telle qu'elle est décrite par les ressources humaines de BPCE – implémenter des fonctions dédiées, surveiller la qualité… – représente une surcharge d'activité résolument incompatible avec l'objectif ultime d'agilité des projets, qui aurait avant tout besoin de rationalisation et d'allègement des contraintes. Heureusement, la présentation que font de leur métier les collaborateurs interviewés (ici et là), centrée sur un modèle de coaching, est plus cohérente.
Toujours est-il que, dans les grands groupes, la même tendance profonde est là, systématiquement, lors de chaque évolution technologique, méthodologique ou autre (« DevOps » n'est qu'un exemple parmi d'autres) : aucun progrès ne serait possible sans créer une nouvelle fonction et recruter les experts ad hoc. Hélas, à force d'additions, l'organisation se complexifie, les responsabilités se diluent, les obstacles se multiplient… et les projets sont de plus en plus longs à faire aboutir, à l'opposé du but recherché.

L'enjeu prioritaire dans ces circonstances relève d'abord d'une transformation des habitudes, de l'adoption de nouvelles manières de travailler, autrement dit, d'un changement de culture, qui ne peut venir d'un élément externe. Il doit impérativement émaner de l'intérieur. Alors, oui, l'apport d'une formation ou d'un coaching est un composant indispensable, mais il n'est qu'un point de départ, une étincelle initiale enclenchant une dynamique qui ne produira de résultat que si elle s'auto-entretient.
L'appropriation des démarches « DevOps » par l'ensemble des individus concernés, seule capable de générer les bénéfices attendus, ne peut opérer que si chacun d'eux y prend une part concrète, sans pouvoir compter sur un spécialiste attitré sur qui se décharger de ce qu'il considèrerait hors de son champ de compétences. Le meilleur moyen de parvenir à cette cible consiste probablement à faire diffuser les pratiques souhaitées par capillarité, de proche en proche entre employés, à travers un dispositif formel ou non.
Ma conclusion tient dans une conviction : « DevOps » n'est pas un métier, ni un intitulé de poste, ni un titre pour une petite annonce. Ce n'est qu'une corde de plus (parmi tant d'autres) à ajouter à l'arc des professionnels de l'informatique, soit, dans un premier temps, le nom de leur prochaine formation, puis une discipline qu'ils appliquent dans leur quotidien. Les entreprises s'étoufferont rapidement si elles persistent à accumuler les recrues pour chaque savoir-faire requis. Elles doivent privilégier les couteaux suisses.