Pour le public non-geek, il faut savoir que les méthodes organisationnelles utilisées pour développer du logiciel sont en pleine évolution depuis quelques années, avec l’arrivée de ce qu’on appelle les “méthodes agiles”. Petite introduction, les experts (dont je ne fais pas partie) voudront bien me pardonner les approximations.

Jusqu’à la fin des années 90 (et même un peu plus tard), les méthodes de développement informatiques étaient calquées sur les méthodes d’ingénierie classiques du monde matériel. Quand on veut construire un bâtiment, on demande d’abord à des architectes, qui vont passer un certain temps à écouter leur client et à définir des plans précis de ce qu’il faut construire. Quand les calculs et la rédaction sont terminés, la réalisation est confiée à des ouvriers, qui vont alors passer la majeure partie du temps du projet à construire le bâtiment.

Antique-Architects-Folding-Rule-02D1208_1-2400
Creative CommonsAntique-Architects-Folding-Rule-02D1208_1-2400” par Garrett Wade

Le monde de l’informatique étant relativement jeune à l’époque, on s’est inspiré de ce qui marchait bien ailleurs, et on a suivi la même organisation : un architecte logiciel traduit les besoins exprimés par le client en un document qu’on appelle “spécifications”, qui décrit quelles fonctionnalités le logiciel aura, et comment il fonctionnera. Ensuite, ce document est transmis à une équipe de développeurs qui va programmer le logiciel.

Spécifications

Au bout de plusieurs années, on s’est finalement rendu compte que ça ne fonctionnait pas, parce que le monde du logiciel est très différent du monde matériel, notamment en terme de temps nécessaire pour les différentes étapes, et en terme de vitesse d’évolution des besoins des clients. On s’est rendu compte que les besoins des clients évoluaient trop vite par rapport au temps nécessaire à la production du document de spécifications. Si vous êtes intéressé par les détails de cette comparaison, voici l’excellent article d’origine, que j’encourage tout professionnel de l’informatique à lire.

Pour en revenir à notre sujet, les informaticiens ont commis une erreur de jeunesse : ils ont essayé de figer dans le marbre quelque chose qui est intrinsèquement changeant : le besoin du client. Devant cet échec, ils ont inventé d’autres méthodes, appelées méthodes “agiles”, dont l’objectif n’est pas de bloquer le changement mais de s’y adapter (démos, itérations courtes, backlog, etc.). Ces méthodes sont très généralement reconnues comme une avancée positive, une évolution de la maturité de l’informatique en général : en reconnaissant que le changement est inévitable et en cherchant à s’y adapter, on est mieux en phase avec la réalité.

Bhutan: prayer bubbles
Creative CommonsBhutan: Prayer Bubbles” par babasteve

Et c’est là que je vais faire le pont (voire le viaduc) avec le bouddhisme. Pour le bouddhisme, l’égo est une erreur d’interprétation de la réalité : l’Homme aime la stabilité, donc il se construit mentalement une sorte de “personne” qu’il considère comme ayant une existence propre, alors qu’en fait il n’en est rien : nous ne sommes que l’accumulation de nos expériences, de nos décisions, et de notre flux de conscience. Tout change, et tout est inter-dépendant.

Selon le bouddhisme, ou du moins ce que j’en ai compris, ce qu’on appelle “moi” ou “égo” n’a pas de réalité en soi, ce n’est qu’une convention. Quand on nomme un fleuve “Amazone” ou “Gange”, il s’agit d’une convention, il n’y a rien de concret et de stable dans ce fleuve (même son lit varie en permanence). C’est pour cela que le bouddhisme dit que l’égo est une imposture qu’il faut démasquer, une inadéquation avec la réalité.

De la même façon que l’informaticien cherchait à produire un document de spécification stable, fixe, en ignorant le fait qu’au fur et à mesure de sa rédaction il divergeait de plus en plus de la réalité, nous nous sommes mis dans la tête qu’il existe un “moi” ou un “égo” stable, fixe, et qui correspond à notre identité. Dans les deux cas, c’est une dissonance avec la réalité qui cause beaucoup de souffrances : l’informaticien refuse ou proteste de manière véhémente quand on le force à reconnaître que les besoins du client ont changé et qu’il faut modifier sa spécification, et l’humain se sent vexé voire insulté quand on met en lumière l’écart entre son égo et la réalité.

Les méthodes agiles, comme le bouddhisme, proposent de reconnaître que le changement est inévitable et qu’il vaut mieux savoir s’y adapter, plutôt que de s’accrocher à une stabilité éphémère et illusoire. C’est un progrès dans ce que le bouddhisme appelle la connaissance, c’est à dire tout simplement l’adéquation avec la réalité. On peut aussi parler de maturité. À la différence bien sûr que le bouddhisme travaille sur quelque chose de beaucoup plus fondamental que la gestion de projet informatique : l’esprit humain.