Quand vous faites partie du second groupe, ou quand vous travaillez dans le développement d’applications, vous apprenez rapidement qu’il existe, au-delà de l’heure, du jour, de la semaine, une unité de mesure capitale : le jour-homme.

Je me dis depuis quelque temps qu’on pourrait même entériner un nouveau mot : le « jourhomme », que la réforme de l’ortografe transformerait en « jourome », et ça serait sympa. Sans parler bien sûr du jourfemme qui devra exister impérativement. Mais je m’égare.

Comme son nom l’indique presque, le jour-homme correspond au travail d’une personne pendant une journée. Ca fait beaucoup rire nos amis anglo-saxons de nous voir utiliser une telle mesure qui passe sous silence toute discussion éventuelle sur la valeur du référent… Il nous faut alors leur expliquer que par chez nous, la durée « officielle » d’une journée de travail est de 8 heures, même s’il s’agit en fait d’une durée admise comme standard – avec toutes les élasticités bien commodes que ça implique, et qui permettent de faire au besoin rentrer deux « jours » en une journée (ben oui, il suffit de travailler de 8h à minuit, fastoche).

Quand on estime une charge de travail, on la chiffre donc en jours-homme.
En général, on colle ça après dans un calendrier (avec ou sans l’aide de certains logiciels pas lourds du tout dont le nom commence par « pro » et se termine par « ject »), et ça nous donne un planning, autrement dit une représentation dans le temps de la vie des vraies gens, week-end et autres jours chômés inutiles pris en compte.
Il est étonnant de remarquer à quelle vitesse on finit à force de faire cet exercice par penser en multiples de 5, et par assimiler 1 mois au chiffre 20 (ce qui est par ailleurs souvent inexact, mais bon, à la louchasse, c’est ça). On met en général plus de temps à intégrer comme un réflexe le calcul inconscient de marges de sécurité conséquentes (de 20 à 50%).

Toujours est-il qu’à l’arrivée, on présente au client un planning, dans lequel il ne regarde en général qu’une seule date, celle de la livraison. C’est le moment où il fait des grands yeux, voire devient livide, voire s’énerve, voire tout ça en même temps ou dans un ordre aléatoire.

Mais, tenez-vous bien, ça n’est pas grave. Pourquoi ? Tout simplement parce qu’on va pouvoir optimiser le planning. Et c’est quoi la solution magique pour optimiser le planning ?

Oui, vous avez trouvé : la parallélisation.

La parallélisation, c’est cette bonne idée qui consiste à dire qu’on va mettre plusieurs gars sur le coup (ou filles, hein, enfin si seulement on en avait dans l’équipe de développement), et que paf par magie ça va linéairement diviser le temps de production par le nombre de ressources affectées. En gros (si vous êtes un peu malcomprenant), s’il y a 60 jours-homme, en mettant deux développeurs, ça va être fait en 30 jours.

Jusque là, je n’aurais presque rien à dire. C’est presque vrai, c’est même presque malin, voire presque réaliste. Sauf que vous connaissez les gens : il leur en faut toujours plus (les coquins). Donc vas-y que jte mets 4 développeurs et c’est torché fait en 15 jours ! Vous voyez venir l’écueil (enfin, j’espère, c’est pas faute d’être lourdement didactique) : tant qu’on y est, mettons 60 développeurs, et ce soir c’est plié.

Sans parler de l’incongruité en termes d’écosystème (essayez de regrouper 60 développeurs et vous comprendrez), on a évidemment oublié un détail dans cette équation, trois fois rien, un mot innocent : la ré-a-li-té.

Eh oui. Dans la réalité, répartir la charge induit très vite des « coûts » collatéraux, notamment en coordination du travail. S’il est souvent envisageable de séparer les tâches en plusieurs lots, il n’est pas dit qu’ils puissent être, d’un point de vue logique, tous réalisés en parallèle.

C’est chiant, la réalité, ça marche pas toujours comme les maths ; par exemple, un lapin plus un lapin, pour peu qu’ils soient de sexe différent, ça a vite des chances de faire plus de deux lapins. Vous me direz : ah mais il s’est passé quelque chose.  Mais justement, ce qui est caractéristique de la réalité, c’est qu’il s’y passe des choses, et qu’il y a des contraintes qu’on ne peut pas réduire, même si on est très bon en maths.

J’aime bien recourir à une image qui fait en général son petit effet. Elle n’est pas de moi, je crois l’avoir trouvée quelque part dans un machin imprimé, un livre, là, mais je ne retrouve pas la référence, et Google est curieusement un peu muet sur le sujet. En la sortant au bon moment, le résultat est garanti :

Si on met 9 femmes enceintes en parallèle, on n’aura pas un enfant en 1 mois.

Si vous faites bien vos devoirs, vous ne devez toutefois pas prendre cette superbe saillie pour argent comptant, et questionner l’analogie (n’est-ce pas). En d’autres termes, demander si développer une application, c’est comme faire un bébé (je vous passerai toutes les bonnes blagues auxquelles ça peut me faire penser, sinon on va y passer l’hiver).

Soyons prudent sans faire de la langue de bois : oui, il y a dans les processus de développement des étapes, qui ne peuvent que s’enchaîner et donc pas avoir lieu en même temps. Il faut pour cette raison ne pas hésiter à affirmer que :

• le temps nécessaire n’est pas linéairement divisible par le nombre de ressources affectées ;
• l’augmentation du nombre de ressources accroit de manière exponentielle les tâches de coordination, et tend pour cette raison très  rapidement à annuler le gain de temps nominal (voire à l’inverser, c’est-à-dire à faire perdre plus de temps qu’on en gagne).

Selon les métiers et les projets, le point de la courbe où la tendance s’inverse est plus ou moins vite atteint, mais d’expérience on constate qu’il l’est toujours plus vite que ce qui serait nécessaire pour satisfaire des plannings irréalistes. Et le plus difficile, c’est de le faire comprendre aux « décideurs » (car les coupables ne sont pas toujours les clients, si si…)

D’où les 9 femmes. Ça n’est pas magique, mais ça peut avoir son poids dans une argumentation.

Divers livres et endroits du web m’ont indiqué que cette tradition était typiquement française , je ne sais pas s’il y a de quoi s’en réjouir. Sans parler du fait que la distinction MOA/MOE, notamment, impose une séparation assez artificielle entre le métier (client) et la technique (prestataire), qui finit par opposer politiquement les savoir-faire plutôt que de viser à les faire se rencontrer, sans parler non plus du fait que si dans l’informatique ou les applications web tout se passait comme lors de la construction d’un bâtiment, on perdrait sans doute moins de cheveux , sans parler de tout ça donc, même si maintenant c’est un peu fait, je voudrais élever rediriger le débat (ben tiens) jusqu’à la question de l’opportunité et de la pertinence de certaines métaphores fréquemment utilisées dans notre beau métier (les applications web).

Sans grande surprise, quand quelqu’un dans ledit métier, client ou prestataire, se lance dans une métaphore filée , il puise dans le champ lexical du bâtiment. Déduction (maintenant possible) : il est français ; bon, en général, on le sait déjà.
De manière un peu plus surprenante, quand ça se produit, ne me demandez pas pourquoi mais neuf fois sur dix il ou elle prend l’exemple d’un carreleur. Celui qui pose le carrelage, quoi, vous savez le truc par terre, là. Pourquoi le carrelage ? No sé ; on demandera à Freud de se pencher sur la question. Bref.
La suite de l’histoire, car il s’agit toujours d’une histoire personnelle, se résume dans les grandes lignes à :

1. le carreleur a fait un devis précis sur le nombre de mètres carrés à couvrir, voire dans les meilleurs versions, sur le nombre carreaux
2. il l’a fait signer avec le sang et il a demandé un acompte
3. il a réalisé le travail, et toute demande supplémentaire a été facturée

Cette narration édifiante (rappelez-vous l’étymologie d’édifiant) se termine par une conclusion en forme d’exhortation : si un carreleur peut le faire, il n’y a pas de raison qu’on ne puisse pas y arriver également, et appliquer cette façon de travailler !

C’est là que je dis : attention, Maurice (mettons que la personne qui a raconté son histoire s’appelle Maurice). Les raisons, s’il s’agit d’en trouver, il peut y en avoir plein. Je dirais surtout trois choses :

1. Ça n’est pas parce qu’une histoire est imagée, avec un exemple de la vie quotidienne (comprenez : concret et qui va parler à tout le monde), moult détail et foult anecdote dont l’authenticité le dispute à la théâtralité, qu’elle impose nécessairement comme une conséquence irrévocable et pour ainsi dire congénitale sa vérité, et, encore moins, son caractère de preuve.
   Pour le dire avec moins de mots : fezez gaffe aux images ! Rien ne va de soi, et surtout pas le choix d’une analogie (le mot est lâché ). D’une manière générale, l’image a tendance à endormir l’intelligence, parce qu’elle s’impose aux yeux en un seul morceau .
2. Conséquence du point précédent : quand il y a une métaphore filée, questionnez l’analogie. Nétadire ? Nétadire qu’avant de prendre pour argent comptant la conclusion de Maurice, demandez-vous si la relation qui est établie entre, dans notre cas, le fait de poser des carrelages et celui de développer une application web, est effectivement pertinente. Les analogies, c’est bien, mais on n’est pas obligé d’être d’accord avec les choses qu’elles présupposent, par exemple que carreler c’est la même chose que faire un site web.
   Déjà, dans la réalité, je connais peu de clients qui demandent l’équivalent de « mettez-moi tel carrelage sur ces 12 mètres carrés » ; au quotidien, ça donne plutôt quelque chose comme « j’ai une pièce à refaire, je ne sais pas trop sa surface, mais il faut que ça soit moins salissant », suivi après livraison de « ah mais il allait de soi qu’il fallait aussi faire les murs, enfin ».
3. Ensuite, et c’est surtout ça le point important, faire une appli web, ça n’est pas poser du carrelage ; s’il fallait tenter d’induire quelque analogie dans le domaine du BTP, ça nous donnerait plutôt : « en général, faire une appli web, c’est comme construire une maison avec un nombre de pièces qui évolue en fonction des actions des habitants, dont la porte les reconnait et leur propose une salle à manger différente selon l’heure de la journée, avec des escaliers dont le design doit pouvoir être revu toutes les trois semaines sans empêcher les gens de les utiliser, un toit qui protège des intempéries existantes mais aussi non connues à ce jour, une pièce qui fait les déclarations de revenus, déclenche automatiquement le paiement des factures, engage ponctuellement du personnel de ménage… Tout ça avec une maison de backup qui chaque nuit sauvegarde tout ce qui a été dit ou pensé par les habitants. Ah oui, c’est pour dans six semaines. »

Évidemment, tout de suite, l’histoire de carrelage tombe un peu à plat.
Mais, pour finir sur une note optimiste, disons qu’elle n’est pas complètement inutile, spécialement si on la considère pour ce qu’elle peut être : une idée régulatrice, autrement dit quelque chose qu’il faut viser.
L’intérêt éventuel de ce que nous a raconté Maurice, c’est de dire : les enfants, pour éviter les débordements, il faut toujours garder à l’esprit que le projet doit tendre le plus possible vers le carrelage. Ça ne sera jamais aussi « simple », mais il faut viser la simplification, l’explicitation des besoins, et les cadrer pour qu’ils soient réalistes et raisonnables. Personne ne demanderait à un carreleur de poser trois niveaux de carrelage, et en or massif, et puis aussi de refaire les peintures au passage (pour le même prix, il va de soi). Ben voilà. Pour nous, ça doit être pareil.

Moralité : la prochaine fois que vous entendez parler de carrelage, soyez attentifs à ce qu’on essaie de vous refourguer comme théorie, il y a de fortes chances pour que ça ne soit pas vraiment approprié.