Vous vous êtes fait connaître en développant la méthode « extreme programming ». Pouvez-vous nous expliquer de quoi il s’agit ?

Ce n’est pas simple, mais je m’entraîne à l’expliquer depuis 25 ans ! Quand je suivais mes études, la façon dont on nous enseignait le développement informatique reposait sur tout un tas de documents, de structures, de formalités, etc. Ce que j’ai remarqué, c’est que la plus grande partie du temps qu’on consacrait à ces éléments était tout simplement perdu, gâché. On écrivait des documents que personne ne lisait, on prenait des décisions qui devaient être modifiées plus tard car quelque chose s’était passé entretemps… Donc, quand je me suis retrouvé en position d’influencer certains projets, je suis revenu aux fondamentaux. Quels sont-ils ? Il faut écrire du code, c’est une certitude. On doit aussi prévoir des tests, pour s’assurer que le code fasse ce à quoi on s’attendait. Et on doit par ailleurs, nécessairement, avoir des conversations avec des gens qui sont très différents de nous, les « geeks ». Tout le reste – cet outil, ce diagramme, ce document à remettre –, je me suis dit qu’on aller passer par-dessus et voir ce qui se passe. L’objectif de cette méthode est donc de ramener le développement à une conversation entre un programmeur qui dispose de la capacité à résoudre le problème et un utilisateur qui a un problème nécessitant une solution. Il s’agit de maximiser cette conversation et de voir si le reste se met en place tout seul.

A l’époque – nous sommes en 1996 –, cette approche était considérée comme particulièrement innovante…

Elle était même « choquante », selon certains. Les gens nous disaient : « non, il faut obligatoirement passer par ces étapes, faire ci ou ça ». Nous leur répondions : « et qu’est-ce qui se passe si on ne le fait pas ? »  Il s’est avéré que quand on a des relations interpersonnelles fortes dans une équipe, et qu’on maximise le temps passé à travailler ensemble sur des objectifs communs, le reste du développement se déroule quasiment tout seul.

Vous êtes aussi connu pour être l’un des premiers signataires, en 2001, du « Agile Manifesto », qui consacre les méthodes agiles. Celles-ci sont aujourd’hui très largement répandues. Mais cette méthode, qui a désormais plus de 20 ans, est-elle toujours capable de répondre aux besoins actuels des organisations ?

Tout d’abord, je ne suis pas seulement l’un des signataires de ce manifeste, je suis, alphabétiquement, le premier signataire. Il s’agit d’un élément que je rappelle à tous les cosignataires dès que l’occasion se présente (rires). Plus sérieusement, je pense que les structures de pouvoir d’alors – qui décide, qui a la possibilité de dire ce qu’il faut faire – sont restées en place. Or, ce qu’on essayait de faire avec ces nouvelles méthodes était précisément de transférer une partie de ce pouvoir. Cela part d’un constat : les personnes qui financent un projet et qui, bien souvent, veulent imposer certaines choses, comme une date à laquelle un logiciel doit être prêt par exemple, n’ont en réalité pas le pouvoir de le faire. Vous pouvez certes imposer des conséquences si la date n’est pas tenue, mais c’est tout. Nous proposions de laisser tomber cette façon d’exercer le pouvoir, dans la mesure où vous ne pouvez de toute façon pas contrôler certains éléments, comme le moment où le projet sera terminé. Pourquoi, dès lors, ne pas laisser tomber cette illusion de contrôle ? Les gens n’ont toutefois pas voulu de ça. Ils souhaitaient conserver les structures de pouvoir telles qu’elles existaient. Et ils ont fini par obtenir les mêmes résultats et les mêmes frustrations par rapport au développement que ce qu’on connaissait avant. Est-ce que cela valait la peine de tenter une nouvelle approche ? Oui, il fallait essayer. Mais les résultats ont été tellement éloignés de ce qu’ils auraient pu être…

Diriez-vous que cette méthode n’a pas d’efficacité particulière ?

Elle en aurait eu si les gens l’avaient réellement appliquée. Mais elle est en réalité revenue à ce qu’était le développement en cascade. Aujourd’hui, on nous explique qu’on va faire une analyse agile du marché, puis un design agile du système, et enfin une implémentation agile de ce design qui correspond à l’analyse de marché… Cela ne correspond pas à la vision que l’on défendait à l’époque. « Agile » est aujourd’hui un « buzzword » et une excuse pour continuer à faire les mêmes choses inefficaces. A part que les gens ne peuvent désormais plus s’en plaindre car c’est « agile »…

De manière plus générale, que pensez-vous du développement actuel de la tech ?

Le secteur a fait des progrès énormes pour accélérer le développement. Nous sommes aujourd’hui capables de mettre des logiciels sur le marché à intervalles plus courts. C’est vraiment une tendance que j’ai perçue tout au long de ma carrière : au départ, on devait pouvoir produire un logiciel tous les 5 ans, puis ça a été une fois par an, par trimestre, par mois, par jour… Cette tendance va se poursuivre, malgré certaines résistances, comme le fameux « don’t release your software on Fridays ». Or, à mon avis, si on n’est pas capable de livrer un logiciel un vendredi, le plus important est de chercher à savoir pourquoi c’est le cas, et de régler ce problème au plus vite… Malgré les importants progrès réalisés, je constate tout de même que je reviens beaucoup aux sujets d’ « extreme programming » dont je parlais il y a plus de 20 ans. Et à chaque fois, je me dis « est-ce que je dois encore vraiment parler de ça » ? Je constate encore, par exemple, que les décideurs essayent souvent de réduire les coûts ou de limiter le temps dévolu pour le projet. Or, cela va toujours poser problème à un moment. En réalité, les deux seules choses utiles et positives que les gens qui financent un projet peuvent faire sont : réduire l’étendue du projet, d’une part, ou insister pour en augmenter la qualité. C’est tout.

Malheureusement, bien souvent, les gens pensent encore qu’en appliquant un maximum de pression, on obtient de meilleurs résultats. Mais ce n’est pas le cas.

Qu’est-ce qui a le plus changé depuis vos débuts dans cette industrie, il y a plus de 40 ans ?

L’échelle. Quand je travaillais pour Facebook, j’écrivais du code qui allait affecter l’expérience de milliards de personnes. Au départ, on parlait de toucher quelques milliers de personnes, puis cela a été des millions, des milliards, et finalement la planète entière. Aujourd’hui, nos décisions ont des conséquences à l’échelle globale, que l’on parle de consommation d’énergie, de disruption sociale ou d’instabilité politique. Nous n’aurions jamais imaginé pouvoir être en position d’avoir de tels impacts à une telle échelle il y a 40 ans.

Que pensez-vous de l’évolution de Facebook, vous qui y avez travaillé entre 2011 et 2018 ?

Facebook, en tant qu’organisation, a été conçu pour tirer profit des opportunités émergentes. Dès lors, l’entreprise a toujours cherché à trouver une façon d’obtenir plus d’utilisateurs, de faire en sorte qu’ils passent plus de temps sur le réseau social, qu’ils envoient plus de messages, qu’ils postent plus de choses, qu’ils interagissent plus…

Selon moi, les produits qu’on développe passent par trois phases. La phase d’exploration, d’abord, au cours de laquelle vous ne savez pas ce qui va marcher ou non. Elle est suivie des phases d’expansion rapide, où on résout les problèmes permettant d’assurer sa croissance, puis de celle d’extraction, qui parachève le travail pour atteindre une croissance durable.

Vous passez donc d’une situation où vous n’avez rien à perdre à une autre où vous avez tout à perdre. Au cours de ce processus, vous devez donc idéalement développer les compétences permettant de mitiger les risques qui peuvent se présenter. Mais Facebook n’a jamais fait ça. Ils ont toujours simplement voulu avoir plus d’utilisateurs. J’avais d’ailleurs lancé un « joke project » quand je travaillais là-bas, qui s’appelait « 1e10 » ou « 10 milliards ». Il s’agissait de savoir comment on allait arriver à obtenir 10 milliards d’utilisateurs… sachant que nous ne sommes pas 10 milliards d’êtres humains sur Terre. Nous exposions, dans notre plan, comment nous allions connecter des dauphins, des primates, ou comment la colonisation de planètes nous permettrait d’atteindre cet objectif. En faisant ça, nous cherchions à montrer qu’on ne peut pas croître au-delà d’un certain point, c’est-à-dire, pour Facebook, quand on a connecté tout le monde. Mais Facebook n’a jamais été culturellement préparé pour faire face à la puissance de l’outil qu’ils avaient développé, et à la responsabilité liée. Aujourd’hui, ils ont complètement perdu de vue la façon de développer correctement de nouveaux produits. Ils en choisissent juste un qu’ils estiment être le plus porteur et déversent des milliards pour le faire aboutir. Cela donne des choses comme le métavers. En réalité, ils sont de retour à la phase d’exploration, mais celle-ci nécessiterait de petits investissements, des expérimentations, pas des financements massifs.

Vous êtes également très investi dans la formation. Comment devons-nous transformer la façon dont nous formons pour attirer plus de gens dans le domaine de la tech, qui en manque cruellement ?

Je crois qu’il faut commencer par travailler sur la façon dont le public perçoit les interactions sociales dans le domaine de la programmation. De très nombreuses personnes ont les capacités intellectuelles pour devenir développeurs, mais ils entendent ces histoires de programmeurs qui travaillent dans des coins sombres, avec des morceaux de pizza qui traînent dans la pièce. Cela ressemble à un enfer pour une personne sociable. Je crois pourtant que, pour être un programmeur efficace, il faut avoir des compétences sociales et les entraîner. Les meilleures équipes, comme celles que nous avons ici, chez Lifeware, sont constamment en discussion. Changer la perception du public, qui pense souvent que les développeurs sont des personnes étranges, qui portent des vêtements récupérés dans une benne à ordures, me paraît donc essentiel pour attirer de nouvelles personnes dans ces métiers. Concernant l’enseignement en lui-même, je pense qu’on doit plus mettre en avant la beauté intellectuelle qu’on trouve dans la programmation, mais aussi le fait qu’elle est un moyen de connecter les gens entre eux.

Vous êtes aujourd’hui de passage au Luxembourg, dans les locaux de la société dont vous étiez l’un des premiers actionnaires, Lifeware. Pourquoi était-il important pour l’entreprise de s’installer ici ?

J’ai rejoint la Suisse pour travailler sur ce projet dès 1997, emmenant ma famille avec moi. Si la décision a été prise d’installer notre siège européen au Luxembourg, c’est parce que le pays, dans le monde de la finance, a des qualités qu’on ne trouve nulle part ailleurs en Europe. On y retrouve cette combinaison intéressante entre une réglementation favorable, une histoire liée à cette industrie, un branding poussé autour du pays, de nombreux talents et une facilité à créer des connexions entre acteurs. Cela me semblait normal de visiter les lieux et de discuter avec les développeurs sur place. En outre, j’ai aussi une casquette de Chief Scientist au sein d’une start-up américaine appelée Mechanical Orchard, dont l’objectif est de remplacer le plus efficacement possible les anciens systèmes informatiques. Une série d’entreprises luxembourgeoises sont dans ce cas de figure et je suis aussi là pour leur parler de ce que peut leur proposer notre start-up.

Lifeware est une société d’assurance-vie. Comment la technologie va-t-elle contribuer, dans les prochaines années, à faire encore progresser ce secteur ?

La première chose dont m’a parlé Massimo Arnoldi, l’un des fondateurs de Lifeware, quand je l’ai rencontré, est la visée sociale de l’assurance. Quand des choses difficiles se produisent, la société, dans son ensemble, assume les aspects négatifs de ces événements. L’accès à ce service fondamentalement social est toutefois limité en raison de l’histoire de ce produit, de la régulation qui y est liée. Lifeware est là pour mettre à disposition d’une plus grande partie de la population les bénéfices de l’assurance. Une des façons de le faire est de faciliter, avec des outils dédiés, l’accès à ces produits et leur gestion, comme le fait Lifeware. Une autre solution est de développer de nouveaux produits innovants. C’est dans ce but que nous avons développé Squarelife, une sorte de laboratoire qui nous permet de lancer des produits en l’espace de quelques jours, plutôt qu’en quelques années, et de voir si telle ou telle proposition d’assurance pourrait plaire à un certain public. Cela permet au secteur de l’assurance de trouver d’autres moyens de dégager de la valeur.

Au-delà de votre carrière professionnelle, vous êtes aussi un joueur de poker et guitariste accompli. Y a-t-il une connexion entre ces passions et votre métier ?

Je suis musicien depuis que j’ai l’âge de 8 ans. Je me suis évidemment lancé plus tard dans la programmation. Mais, comme de nombreuses autres personnes, j’ai rapidement pu percevoir certains parallèles entre l’activité de musicien et celle de développeur. Mais je n’ai réellement réussi à les comprendre que lorsque j’ai commencé à jouer au poker. Quand on joue au poker, on se retrouve souvent dans une situation où un joueur place une mise, puis le suivant une autre, et on cherche à savoir ce qui se passe. Puis, tout d’un coup, on se dit « oooh, je sais exactement quelles cartes vous avez » ! Ces moments de « pattern recognition » offrent une grande satisfaction. J’expérimente souvent la même chose en programmant, quand je cherche la solution et que je la trouve finalement. Cela se passe aussi en musique, quand on débute une phrase et qu’on se demande comment la finir. Puis on se dit qu’en retardant un rien la dernière note, cela sonne parfaitement. Quand on a une  personnalité addictive, on cherche alors sans cesse à renouveler ces moments de vraie satisfaction…

Lifeware, solution tout-en-un

Lifeware a vu le jour à la fin des années 90 en Suisse, partant du constat que les transformations technologiques, et notamment la généralisation d’Internet, allait bouleverser le modèle de l’assurance-vie. La société a développé au fil des années un outil qui permet à ses partenaires – les grandes compagnies d’assurance-vie – de mitiger leurs risques opérationnels et de réduire leurs coûts opérationnels. La solution prend en effet en charge l’entièreté de leurs besoins (reporting, gestion des produits, des actifs, des documents liés aux contrats, finance, compliance, KYC-AML, etc.), en interconnectant efficacement toute un série de logiciels existants. En arrivant au Luxembourg, Lifeware entend mieux accéder au marché européen, et bénéficier de l’écosystème développé du pays en matière de finance.

The business established its EU headquarters in Luxembourg some six years ago with the support of Matt Moran, PwC’s EMEA Insurance Deals and Value Creation Leader who more recently was also selected to run Technology Alliances at PwC Luxembourg.