Benoît et Tristan travaillent pour Transacteo, éditeur de logiciels pour les agences immobilières. Dit autrement : une boîte d’informatique. Que trouve-t-on dans ce type d’entreprises ? Des informaticiens bien sûr. Plusieurs termes peuvent être utilisés pour les désigner : développeurs, codeurs, tech… Il semble que, tous les 5 ans, on modifie le nom de leur profession. La start-up nation chère à Macron, c’est un peu ça : en changeant d’application ou de mot, on innove à peu de frais.
Le moment est venu de présenter Carine, membre de la mystérieuse confrérie des développeurs. Sur les 15 dernières années, Carine et ses homologues se sont convertis en masse à un nouveau culte , dont ils font l’éloge à chaque réunion : la « méthode Agile ». De quoi s’agit-il ? Avant de répondre à cette question, il nous faut introduire certains aspects typiques des projets informatiques.
Dans ce secteur, il est relativement peu coûteux de réaliser un produit suffisamment fini pour être mis sur le marché. Il faudra au préalable recruter quelques personnes ayant des compétences dans les champs suivants : base de données, infrastructure, développeur « front », développeur « back », ainsi que une ou plusieurs personnes pouvant se mettre à la place des utilisateurs – les agents immobiliers dans le cas de Transacteo. Pour peu que les recrues soient bien câblées, au bout de quelques trimestres, il sera possible de montrer des prototypes assez aboutis aux acheteurs potentiels.
En revanche, s’il s’agit de construire un train ou une centrale nucléaire, ça ne marche pas : il faut non seulement embaucher davantage de personnes, mais en plus, des dépenses devront être engagées pour acheter des équipements nécessaires au projet. Des coûts fixes, comme disent les contrôleurs de gestion.
En informatique, puisque c’est peu coûteux et assez rapide de mettre quelque chose sur le marché, les tenants de la méthode Agile font valoir qu’il n’est pas nécessaire de trop réfléchir à la planification. Les idées viendront au fur et à mesure que le produit sera développé, et de toute manière, dans 6 mois, un prototype sera montré aux acheteurs potentiels, qui diront ce qu’ils en pensent. Au pire, si le produit ne les convainc pas, aucun problème : en quelques mois, le prototype sera adapté pour mieux répondre aux besoins exprimés.
Voici donc mon interprétation des fondements de la méthode Agile, telle que Carine l’a en tête :
avoir une petite équipe dédiée à un projet, qui intègre toutes les compétences nécessaires;
très peu planifier;
proposer rapidement un prototype - « demo or die », disent les spécialistes;
après ce premier essai, sortir rapidement des évolutions, pour progressivement coller aux besoins du marché.
Tout cela est très séduisant, parce que, planifier, c’est drôlement casse-tête et acrobatique. Quand on reproduit une recette, il est aisé d’anticiper. Mais quand on crée un nouveau produit, allez savoir ! C’en est presque humiliant : on écrit des pages et des pages, on fait des schémas, on consulte des gens… et quelques mois après, on se rend compte qu’on avait tout faux. On comprend que les informaticiens soient bien contents de pouvoir s’épargner cette douleur. La méthode Agile a donc deux avantages : elle est adaptée au développement informatique, et elle rend la vie de Carine bien plus agréable.
Tout est pour le mieux dans le meilleur des mondes, jusqu’à ce que les informaticiens se confrontent à leur bête noire : les vieux systèmes, qu’ils appellent « legacy ». En effet, Transacteo n’est plus une start-up depuis longtemps. L’entreprise a été créée dans les années 90, et le socle de ses produits a été développé avec des technologies et des méthodes de travail aujourd’hui obsolètes. Les produits fonctionnent encore, mais les compétences et connaissances se perdent au fur et à mesure que les employés quittent l’entreprise, et sont remplacées par de nouvelles personnes. Et ce malgré la documentation qui a été écrite à l’époque. Le risque est grand que, dans un avenir proche, la société rencontre des difficultés pour maintenir ce socle.
Un jour, Carine et son adjoint Laurent débarquèrent dans le bureau de la présidente pour l’en alerter :
« Ça ne peut plus durer ! La techno utilisée pour notre socle "Iridium" est trop vieille. C’est très dur à maintenir. On court un gros risque : si une panne survient, on n’est pas sûr de savoir la réparer. On joue avec le feu. Il faut le redévelopper sur une techno plus récente.
- Bonjour Carine, pas de problème, répondit la présidente, je comprends, il faut qu’on investisse pour que notre infrastructure soit à niveau. Combien de personnes devons-nous prévoir pour ce projet, et sur combien de temps ? Nos actionnaires vont nous poser la question.
- Combien de temps ? répéta Carine, un peu interloquée. »
Après un temps de réflexion, elle ajouta :
« En fait, nous travaillons en méthode Agile : on développe sur des périodes d’un mois, qu’on appelle "Sprint", et à la fin on voit ce qu’il nous reste à faire.
- D’accord, dit la directrice, je vois… mais il nous faut un peu de visibilité, pour notre direction financière, notre plan stratégique, nos créanciers. Nous avons besoin d’un cadrage du projet, qui l’envisage dans sa globalité. Vous pensez que ce projet va durer plutôt 6 mois, un an ou 18 mois ? Ce n’est quand même pas tout à fait la même chose. »
Carine et Laurent, mal à l’aise, se regardèrent du coin de l’œil : les mauvais souvenirs des années 90 leur revenaient en mémoire. Un cadrage de projet ! C’est-à-dire qu’il allait falloir se projeter, écrire, échanger… Un vrai cauchemar. Ils avaient espéré être débarrassés de ces histoires de planification pour toujours, et voilà que les vieux démons revenaient les hanter.
Carine concéda que la migration du socle n’était pas tout à fait sans risque :
« C’est vrai que c’est un projet pas simple, car le socle est utilisé par plusieurs produits que nous mettons à disposition de nos clients. On pourra migrer de l'ancienne version du socle vers la nouvelle version seulement lorsque que toutes les fonctionnalités auront été développées et testées, ce qui prendra un certain temps. »
Une fois la discussion terminée, les informaticiens se retrouvaient face à un dilemme terrible : d’un côté, maintenir le vieux système, avec son langage abscons, que les jeunes ne connaissent pas, et de l’autre, taper sur leur clavier, écrire des phrases… Quelle douleur !
Au bout de quelques jours, ils prirent leur décision : tout plutôt que de rédiger un document et se lancer dans un exercice de planification. Iridium allait donc rester dans sa technologie obsolète, et tant pis pour les personnes qui seraient contraintes d’y résoudre les futures pannes.