Le monde informatique d’aujourd’hui fonctionne à deux vitesses. Deux philosophies de bases irréconciliables se font face sans se comprendre.
L’une, tirée par les start-up et les géants de la tech (Google, Amazon, Netflix et bien d’autres) qui repoussent chaque jour les limites des concepts technologiques, et l’autre, assise sur ses certitudes et n’évoluant que lorsqu’elle ne peut pas faire autrement, qui est engluée dans ses process et ne voit les choses qu’au long terme.
L’approche industrielle
L’approche, que nous appellerons “industrielle” a donc une vision long terme des choses. Les environnements sont faits pour durer et doivent être réfléchis dans des temps proportionnels à la longévité des infrastructures qui en naîtront. On perd des heures en réunion pour définir chaque point que l’ont détaillera ensuite dans des documents qui ne seront lus qu’une seule fois par les équipes chez qui l’ont repartira les tâches de développement (souvent via des prestataires) sans pour autant leur donner une vision globale de ce qu’on cherche à atteindre.
On aboutit souvent à une dilution des responsabilités et un travail mécanique des acteurs censés amener de la valeur à ces projets dantesques. La déresponsabilisation est d’autant plus grande que ces équipes n’ont pas non plus à maintenir ce qu’elles ont produit, puisque des équipes d’exploitation se chargeront de tout celà ensuite. Avec des délais courts et des budgets serrés, ont fait ce qu’on peut, et tant pis si celà marche tout juste et génère des erreurs.
Les périodes de qualification et de recette du code sont censées gommer les problèmes. L’effort fourni pour la mise en commun du code des différentes équipes est important et souvent douloureux. Mais ces environnements ne peuvent au final jamais être équivalents à ceux à destination des clients, et on n’est jamais sûrs du résultat lors de la mise en production. Pour autant, ces environnements sont un enfer à maintenir et demandent un effort souvent plus grand que la production elle-même pour être maintenus opérationnel pour les développeurs.
La liberté offerte aux développeurs est la plupart du temps nulle ou très limitée, les cahiers des charges étant rédigés souvent bien en amont. Ils sont donc considérés comme des exécutants. Il est ainsi difficile pour eux de vivre un métier “passion”. Il en va de même pour les équipes d’exploitation qui doivent maintenir “à l’aveugle” des systèmes sur lesquels ils ne décident rien. Du temps est perdu à tous les niveaux et le résultats final n’est jamais celui attendu.
Beaucoup de frustration est ressentie à tous les niveaux, tant au niveau des chefs de projets, des développeurs ou des admins et techniciens système. Souvent, plutôt que de remettre en cause le système, on finit par se rejeter la faute d’une équipe sur l’autre et l’ambiance générale peut virer plus sûrement en guerre de tranchées qu’en mise en commun des compétences pour trouver la source des problèmes. Tout ceci est usant et démotivant.
L’approche startup
Nées de toutes ces frustrations liées à cette vision des projets, de nouvelles approches ont vu le jour, comme devops ou l’agilité. Ces philosophies ont un but commun : remettre l’humain au centre des préoccupations et replacer la communication au centre des principes de travail. La responsabilisation des équipes redevient également un enjeu majeur des projets informatiques.
L’approche micro-service amène une subdivision des projets qui permet de réduire les périmètres et donc de les rendre plus facile à appréhender et à maintenir. Selon le principe KISS (keep it simple, stupid), plus les choses sont petites, atomiques, et plus la création, la maintenance et et l’évolution en est facilitée. Un micro-service devient un projet à part entière. L’équipe en charge s’en trouve réduite et la communication est donc meilleure. Lorsqu’un micro-service n’a pas d’évolution prévue, il n’est pas (ou presque pas) utile de le tester. Nos micro-services n’ont pas non plus besoin d’être écrits dans le même langage.
L’agilité permet de traiter de façon collégiale le rôle du chef de projet en fournissant de nombreux outils pour gérer en équipe les tâches à faire et l’ordonnancement des développements au sein de l’équipe. On sait de plus ce que chacun fait et la parole est libre pour discuter des choix et des orientations prises par les autres membres de l’équipe. Celà responsabilise l’équipe qui fait en commun des choix sur la progression des projets.
Le DevOps permet de ramener les métiers du développement et de l’exploitation autour de la même table tout au long de la vie du projet. le DevSecOps étend même les choses aux équipes sécurité. Il s’agit au final d’assumer en tant qu’équipe tous les aspects qui permettront de produire mieux et plus efficacement. On pourrait étendre celà aux équipes UX, ou à tout autre métier dont dépendent la réalisation d’applications qui satisfont au mieux ce/ceux pour quoi/qui elles sont faites.
L’approche Lean startup nous apprend le fail fast. Il ne faut plus avoir peur de l’échec. Il faut amener le plus rapidement possible une idée en production pour valider qu’elle est bonne. On ne va pas passer des mois à cadrer et peaufiner une idée et livrer une version définitive qui pourrait être un échec cuisant. On va produire vite, de façon non définitive les nouvelles fonctionnalités, et l’on poursuivra leur développement que si celles-ci ont eu un accueil favorable ou de bons résultats pour répondre à la problématique pour laquelle elles ont été créées. On livre plus souvent, on mesure les résultats tout aussi souvent et on décide des actions à mener sur le prochain cycle de développement.
Ce sont les principes de base. Cette liste n’est pas exhaustive, et les concepts ne sont pas à prendre comme des règles à suivre. L’équipe doit savoir s’adapter et adapter les méthodes à ses besoins. Ce qui prévaut, c’est de comprendre à quoi elles servent et ce qu’elles peuvent apporter. On y adhère ou pas.
L’approche startup est un mix de ces différentes méthodes appliquées à ce que l’ont veut faire. On apprend à faire du code et des infrastructures “jetables”. On ne cherche plus à créer des projets parfaits. On subdivise les périmètres et les équipes pour favoriser la communication et la simplicité. On apprend à composer avec l’échec au lieu de le redouter. On apprend que la communication est plus importante que les technologies choisies.
Ce que chacun pense de l’autre
Le monde industriel voit le monde des startups comme :
Celui “des modes” où rien ne dure, où la sécurité n’existe pas et les process sont inexistants. Comment faire des applications fiables et produire des infrastructures stables lorsque l’ont travaille dans un environnement de bohème ? On invente des noms de métiers qui ne riment à rien et qui changent tout le temps. On fait fi des méthodes éprouvées que l’on utilise depuis des décennies et qu’on sait être fiables, pour partir vers l’inconnu et utiliser en production des outils qui ne sont même pas en version définitive, comme ce fût le cas pour docker, kafka ou encore terraform. Les startupper viennent donner des leçons alors qu’ils ne respectent pas des règles simples qui régissent la production telle qu’on la connait. On corrige les problématiques de maintenance en supprimant la maintenance et en détruisant tout pour le reconstruire. ITIL vole en éclat et on perd l’amour du métier qui nous permettait de produire des systèmes aux petits oignons qu’on était fiers de montrer pour leur perfection. On perd aussi beaucoup de temps et d’énergie dans des choses qui ne sont pas de l’ordre du travail comme des “sorties paintball”, de la déco d’intérieur dans les bureaux qui ressemble parfois à la déco d’un jardin d’enfants et le fameux “Chief happiness Officer” censé gérer cette bande de gamins gâtés.
Le monde des startups voit le monde industriel comme :
Celui de la lenteur et de la tristesse. Celui où on rentre jeune et passionné et d’où on ressort usé et vidé de tout espoir. Comment faire des applications fiables et des environnements stables quand on reproduit encore et encore les mêmes erreurs depuis de décennies ? Comment s’améliorer quand on ne sait pas évoluer ? Dans un monde qui évolue encore plus vite qu’il n’a jamais évolué, pourquoi prévoir du long terme ? Pourquoi passer des mois à prévoir des projets qui seront obsolètes dès lors qu’ils sortiront ? Pourquoi encore produire des projets d’envergure sans les diviser et encore et encore accuser des retards et finir avec des incohérences avec le projet initial ? Pourquoi perdre autant de temps et d’argent à maintenir des environnements multiples, des outils et langages obsolètes et mobiliser des équipes qui ne se parlent pas et travaillent chacune dans leur coin ? Pourquoi se contenter d’utiliser de vieilles technos alors que tout un tas de nouveaux outils apparaissent et nous permettent d’être beaucoup plus efficaces et de rendre les infrastructures scalables ? Et enfin, pourquoi travailler dans des bureaux tristes et lugubres quand on peut s’amuser au travail ? Car il n’y a pas que le travail dans la vie, et on est beaucoup plus productifs quand on s’amuse et qu’on est heureux.
Pour conclure
Vous l’aurez compris, en ayant vécu les deux philosophies, J’ai du mal à trouver des excuses à ceux qui refusent d’évoluer. Pour autant, je peux comprendre cette peur du chaos et de l’instabilité qu’apporte le fait de devoir se remettre en question sans cesse et de faire confiance à des outils qui changent tout le temps. Certains cadres industriels imposent des règles sur le long terme, comme par exemple des machine-outil qui devront rester opérationnelle en offline pendant 20 ans. Mais tous ne sont pas aussi restreints que celui-ci. Le site web d’une entreprise industrielle ne nécessite pas des process aussi stricts et pérennes que le pilote automatique d’un airbus A320. Il faut savoir être strict et conservateur lorsque c’est nécessaire, mais savoir lâcher du lest quand on le peut. A l’inverse, avoir la possibilité de travailler avec des nouveaux outils n’est pas une injonction à le faire. Si l’ont change tout, tout le temps, il est difficile de trouver à terme une stabilité et une pérennité.
La vérité est donc entre les deux et fonction des contraintes qui s’appliquent au projet. Mais les principes visant à réduire de gros projets en de multiples petits projets indépendants semble être un bon axe d’amélioration. Considérer les multiples équipes comme autant de startups qui ont leurs objectifs, leurs micro-services et leurs clients facilitera la vision globale du projet dans son ensemble.