Un grand logiciel (comprendre volumineux) ne se fait pas seul. Tout un microcosme est mis en place autour de lui pour lui permettre d’émerger, puis d’évoluer. C’est une sorte de société féodale, avec ses paysans et ses notables. Si j’essaie de vous dépeindre ça de façon posée et balancée, je dirais qu’on y retrouve, pêle-mêle :

• des développeurs, qui constituent de loin le groupe le plus nombreux. Les roturiers par excellence. Ils sont souvent dénigrés, voire totalement ignorés par les autres groupes, qui oublient tout de même qu’ils sont la cheville ouvrière du projet et que sans eux, rien ne fonctionnerait non plus. Mais ça ne les excuse pas de profiter de la première opportunité pour tenter de rouler les autres groupes, en livrant des demies versions, ou en se détachant de toute responsabilité quand un problème technique survient ;
• des experts, dans tout un tas de domaines. Plus le domaine est pointu et abscons, plus l’expert est fier et détaché du monde réel, parce qu’il pense être légitimement respecté. Ce qui serait le cas si ses chevilles faisaient office de lest, et son intérêt pour le projet était plus marqué ;
• des architectes. Le rôle de l’architecte est d’avoir un avis sur tout qui fait office de loi. Un représentant de l’Église en somme. Faire respecter la loi est dégradant à ses yeux, il ne s’en charge donc pas. Ce qu’il ignore, c’est que personne ne le fera à sa place. Il est donc tout aussi utile qu’un expert ;
• des intégrateurs. Ils sont les vrais dépositaires du pouvoir et font vivre le projet. Alors, conscients de leurs responsabilités, en bons régents de l’état, ils occupent sagement leurs journées,  en terrorisant les développeurs, en envoyant les architectes manger du foin, et en dénigrant les experts qui sont toujours à parler du cinquième bit du huitième octet de l’entête de la trame réseau ;
• des gestionnaires de configuration. Ils gèrent le code et toute la documentation associée. Ces moines copistes répliquent, reprennent, rangent, sans vraiment comprendre ce qu’ils font. Ils introduisent de l’entropie, en portant à moitié des correctifs, en en perdant d’autres. Ils font bien entendu retomber la faute sur les développeurs. C’est aussi grâce à eux que le projet n’avance pas trop vite. Un bon gestionnaire de configuration sait freiner les autres au-delà du raisonnable, sous couvert d’une bonne excuse technique (« ho ! le serveur a encore rendu l’âme ! Vivement que le support technique installe le patch n°561831 ! ») ;
• des spécificateurs. Ils pensent connaître le produit, qu’ils appellent système pour pouvoir survivre en milieu mondain. Mais comme ils ne discutent pas avec les développeurs, ces sales paysans boueux qui passent leurs journées les mains dans la fange du code, il y a souvent un certain écart entre la théorie et la pratique. Un moment d’humour sans cesse renouvelé consiste à coller un spécificateur devant un banc de validation ;
• des vérificateurs. Ils utilisent des plans de test écrits par les spécificateurs pour valider un logiciel qui ne démarre même pas. Ils passent ainsi toute leur vie assis entre deux chaises, en disant « amen » à tout ce que demande le client, juste avant de se prendre une révolte paysanne bien méritée dans les dents, pour avoir enterriné l’idée que ce serait mieux si le programmateur de machine-à-laver qu’il faut livrer dans deux jours savait aller récupérer le temps de cuisson du poulet sur l’Internet (oui, j’écris l’Internet, ça énerve tout le monde, moi y compris).

Bien entendu, la vérité est bien pire ! J’aurais l’occasion d’y revenir par la suite.