Il était une fois un artisan en informatique. Vous connaissez son histoire. Sa vie lui plaisait et il décida de partager sa connaissance. Il prit donc un jeune apprenti. Ce dernier était doué et acquit rapidement les savoirs de son maître. Certes, il ne maîtrisait pas les outils avec autant de facilité que son tuteur.
Sa formation auprès de l’artisan lui avait apporté les deux aspects de l’informatique : le développement et l’opérationnel. Il avait compris la préférence de son maître pour le code : la possibilité d’automatiser l’opérationnel. Ainsi, un bon développeur pouvait automatiser les opérations de mise en place des services créés.
Cependant, le code l’attirait moins que ce sentiment de puissance de contrôler des dizaines de serveurs avec quelques lignes. Et les projets traités par son mentor lui semblaient trop simples. Un boulanger, un commerçant, un sculpteur ou un charpentier ont des besoins en informatique. Mais cela reste des projets modestes.
L’apprenti voulait se confronter à de plus grands défis. Il voulait appliquer l’art de son maître à l’échelle du pays, pour des projets qui impactent des centaines de milliers d’utilisateurs. Car l’informatique c’est cela: écrire une fois et utilisable à l’infini. Il choisit donc une voie différente de celle de l’artisan.
En soit, ce choix n’avait rien de surprenant. Depuis que l’artisan exerçait, les métiers s’étaient multipliés. Lui-même avait dû faire un choix dans cette foule de technologies apparues. Il n’était donc pas surpris de voir son élève attiré par une ces annonces : recherche un ingénieur DevOps.
Le poste impliquait la capacité d’automatiser la création de logiciels : de sa conception à sa mise en place. Dans les projets informatiques modernes, au moins 5 grandes étapes étaient identifiées :
- le recueil et l’analyse du besoin,
- le développement (le codage),
- la validation (unitaire ou en intégration),
- la livraison – le déploiement,
- la supervision de l’environnement de production,
Suivant la méthode de gestion du projet informatique, ces étapes pouvaient s’enchaîner plusieurs fois par an.
De plus, le poste impliquait un projet impliquant des dizaines d’acteurs pour des milliers d’utilisateurs répartis partout dans le pays. Analystes, concepteurs, développeurs, validateurs testeurs, administrateurs systèmes et réseaux, chefs de projets, … tous œuvraient dans le même but.
Et l’expert DevOps se devaient de leur offrir à chacun des outils afin d’automatiser les échanges entre eux tout en s’assurant de la qualité finale du projet. Ainsi, l’apprenti voyait dans ce nouveau travail un moyen de valoriser les automatismes qu’il avait découvert auprès de l’artisan.
Il ne choisissait pas les technologies utilisées par les développeurs, ni les plateformes techniques sur lesquelles s’exécuterait l’application. De même, les outils de communication entre les différentes équipes étaient déjà en place. Pour le reste, il avait carte blanche pour automatiser les autres maillons de la chaîne.
Son travail était donc de lister les relations entre chaque acteur (humain ou technique) du projet et de proposer des méthodes pour faciliter les échanges. L’apprenti avait pensé à automatiser du développement au à la production avec git, docker et kubernetes. En soit, sa formation auprès de l’artisan était profitable.
Le jeune homme réalisa qu’il existait des dizaines d’alternatives aux outils qu’il avait vu lors de sa formation. Pour autant, les bases enseignées par l’artisan lui permettaient de ne pas être perdu dans cette foule d’outils.
Mais l’apprenti n’avait pas pensé pensé au côté humain d’un projet informatique. S’il est facile d’automatiser les traitements de développements informatiques lorsqu’on met en place les bons outils, faire communiquer les différentes équipes est un autre métier.
Tous les comités de la terre ne servent à rien si l’information ne parvient pas aux bonnes personnes. Et ce défi est bien plus complexe à relever. Avec l’artisan, il suffisait de se parler ou de parler avec les clients. Là, le défi était différent. Mais c’est une autre histoire.