« IL », c’est l’ordinateur, bien sûr. Tentative ultime de raccrocher à une figure un peu anthropomorphisée ce qui se passe en fait dans la machine, autrement dit les programmes qui font des machins. Parce qu’évidemment, tout le monde le sait, l’ordinateur ne fait rien lui-même. Il n’est ni intelligent, ni bête, il fait ce pour quoi on l’a programmé.

Alors pourquoi, pourquoi cette impression si facilement partagée qu’il y a quand même là-dedans une sorte de volonté propre, ou pire, aléatoire (ou encore pire quand vraiment tout va mal, machiavélique)..?

Passons sur notre tendance à l’anthropomorphisme, assez récurrente, réflexe ancestral face à l’inconnu et l’incompris. S’il n’y avait que ça, il suffirait de se moquer et ça serait plié. Non non non. Il y a forcément plus.

Ce qu’il y a, c’est que les programmes qu’on utilise ont depuis longtemps dépassé le stade des micro-routines. Ils représentent parfois des millions de ligne de code, et même s’ils ont été élaborés en suivant les règles de l’art (respect des bonnes pratiques, design patterns, pizza, versionning des sources, etc), leur niveau de complexité excède grandement nos capacités d’appréhension en un seul coup d’œil, pour le dire comme ça.
En d’autres termes, ils ont franchi le seuil au-delà duquel il n’est plus possible pour quiconque de savoir ce qui va exactement se passer dans tous les cas possibles (notamment parce que ces « cas » sont trop nombreux, donc qu’on peut difficilement assurer qu’on les a tous envisagés).

Si on veut recourir à une analogie (tu es nouveau ? Cliquette ici), disons que tout programme dépasse rapidement le stade où on peut croire qu’il est un ensemble fini prévisible, pour devenir un système probabiliste gazeux.

La principale conséquence en est que l’utilisateur (et même le créateur) n’est jamais complètement certain de ce qu’il va faire. Et de quoi est-ce que c’est la caractéristique, au fond, je vous le donne en mille ? De l’altérité.

L’autre. Ce truc qui n’agit pas comme dans ma tête. Bref, sans imaginer bien sûr qu’il ait une volonté propre, le programme a suffisamment d’ « indépendance » pour se comporter comme quelque chose d’aussi imprévisible qu’un être humain, et c’est assez génial (en tout cas à titre personnel je trouve ça exaltant, mais les clients ne partagent pas toujours cet avis, bizarre…)

D’où cette belle formule, qui me sert à briller à la cafeteria ou à clore certains débats stériles : oui, les ordinateurs (en fait : les applications) sont des êtres humains comme les autres.

Et c’est pourquoi bien programmer passe principalement par l’application de bonnes pratiques qui visent à réduire au maximum les interstices où va se fourrer l’imprévisibilité, et à tester au maximum toutes les éventualités qui peuvent se présenter — ce d’autant plus que, en face de l’ordinateur, il y a un utilisateur, qui lui aussi est imprévisible, et qui comme vous l’aurez appris si vous développez, fera toujours exactement le truc que vous n’aviez pas prévu.

_________________________________

Illustration : Marvin le robot dépressif, dans H2G2 – The Hitchhiker’s Guide to the Galaxy

Là où je sévis actuellement, un document interne secret à visée caustique recense ces termes et d’autres ; la liste qui suit s’en inspire librement, avec d’autant moins de scrupules que je suis à l’origine des deux tiers d’entre eux.

- Levier : solution en général fictive mais rhétoriquement commode pour faire croire ou se persuader qu’on a des moyens d’action. Nous avons identifié les leviers à notre disposition pour raccourcir les délais.

- Paralléliser : recours ultime lors d’une négociation de planning, dont le but – fantasque – est de diviser linéairement les temps de production par le nombre de ressources affectées. Voir le post consacré au sujet.

- Pragmatique (ou sa variante réaliste) : attitude consistant à sacrifier la qualité tout en se défendant de le faire.

- Proactivité : technique de management pragmatique consistant à demander au collaborateur de résoudre les problèmes à venir sans les connaître à l’avance.

- Proposition (force de) : Nous attendons que vous soyez force de proposition. Façon aimable qu’a le client de demander au prestataire de faire son travail à sa place.

- Temporiser : pour le client, indique qu’il n’a pas encore pris le temps de trancher les choses dont vous avez absolument besoin pour avancer sur un livrable qu’il exige pour demain. Pour le prestataire, signifie que les développements qui devaient commencer hier avec trois ressources commenceront la semaine prochaine avec une demie. Doit toujours cependant être utilisé dans une phrase qui laisse penser que tout cela est parfaitement volontaire. Nous avons décidé de temporiser.

- Tiroir : dans la vraie vie, élément coulissant d’un meuble ; dans une proposition commerciale, élément coulissant du devis exigé par le client pour se donner les moyen de faire baisser le montant total. Pouvez-vous me faire une proposition à tiroirs ? Attention : dans la pratique, le client choisit toujours de conserver des tiroirs qui ne peuvent être réalisés sans ceux qu’il a retirés.

- Transverse : notion à utiliser en biais ; bien commode pour camoufler son ignorance du contenu exact d’une intervention. Nous avons mobilisé des compétences transverses.

- Valeur ajoutée : concept à utiliser sans parcimonie dans tout discours de vérité (voir ci-dessous). Cette fonctionnalité n’a pas de valeur ajoutée.

- Vérité (discours de) : stratagème circonlocutif, destiné à obscurcir le sens de ce qui est dit sous couvert de transparence (on dit également : « enfumer »). Fonctionne également comme prétérition, pour tenter de rester poli : je vais te tenir un discours de vérité, ton code c’est vraiment de la merde.

Bien entendu, toute ressemblance avec des phrases ayant été prononcées dans la vraie vie serait étonnamment fortuite, etc, pardon aux familles tout ça.

__________________________

Superbes illustrations trouvées fortuitement chez Getty Images.

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.

Il aurait alors fallu agrandir légèrement l’objet, de 115 mm de diamètre aux 120 actuels. Mais comme au pays des légendes on ne peut jamais s’endormir tranquille après une bonne bière et une bonne histoire, une explication concurrente (probablement fantaisiste, n’ayons pas peur de le dire) voudrait que cette taille soit en fait celle des dessous de verre à bière standard des Pays-Bas.

Fantaisie ou pas, ça ne serait pas la première fois qu’un objet du quotidien sert de base arbitraire à une décision engageant ensuite tout un secteur.
Dans un genre proche des verres à bière, et probablement plus crédible, on raconte que les disquettes 5 pouces 1/4 (que certains, y compris moi, ont connu ; c’était il n’y a pas si longtemps encore, sales jeunes) devaient leur taille à un autre objet célèbre dans les bars et restaurants. Si si.

Voilà l’histoire : alors que les disquettes 8 pouces, le premier standard de l’histoire, commençaient à encombrer franchement les utilisateurs (20 centimètres de large, pas simple à ranger dans son sac à main, jvous raconte pas), les laboratoires Wang demandèrent à l’un des associés du créateur de ladite disquette de travailler à un modèle plus réduit.
Lui :  « quelle taille elle doit faire ? »
Eux :  (en montrant une serviette de table) « oh, genre ça ».
(Je sais, j’ai un grand talent de conteur).
Il n’en aurait pas fallu plus pour que les disquettes, pendant près de 20 ans, fassent 5 pouces 1/4 . La taille d’une serviette de table.
On raconte également que le successeur, la disquette 3 pouces 1/2, fut conçue de façon à tenir dans une poche de chemisette américaine standard. Je n’ose pas imaginer ce qu’on pourrait trouver comme légende pour l’invention de la clef USB… Rhem.

Ainsi en va-t-il souvent des spécifications (voix caverneuse). Il n’est pas toujours question de nombre d’or ou de grands desseins galactiques mais, comme dans les meilleures traditions de création littéraire, c’est souvent au bistrot que ça commence.
C’est souvent là que ça finit aussi, mais c’est une autre histoire.

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é.

L’un des grands principes que cette déjà longue et enrichissante vie m’a permis de dégager est le suivant :

Ne pas prendre les gens pour des imbéciles, mais ne jamais oublier qu’ils le sont.

Les gens, ça vaut pour moi aussi, bien sûr ; ça ne veut pas juste dire les-autres-alors-que-moi-je-suis-génial . La base phizolophique de ce précepte est donc toute empreinte de misanthropie (à mes heures perdues, je suis assez misanthrope) ou, pour être plus sympa – et après tout, pourquoi ne serais-je pas plus sympa avec moi-même, se veut un appel à l’humilité. Il aurait pu s’énoncer « si tu trouves que les autres sont cons, dis-toi bien que tu es au moins aussi con qu’eux », mais ça claquait moins, il faut le dire.

Dans la vie de tous les jours (ouvrés), où mes attributions professionnelles m’amènent à côtoyer toutes sortes d’individus qu’on regroupe sous le vocable aussi générique que flou de « client », ce principe a une moultitude d’intérêts et d’applications pratiques.
Il aidera ainsi à éviter de formuler des questions comme si on s’adressait à un demeuré.
Par exemple, ne pas dire « Mais vous êtes sûrs que quand on clique sur Sauvegarder, ça sauvegarde ? » (= vous le prenez pour un abruti, MAL), mais préférer « Que se passe-t-il quand on valide le formulaire ? » (= vous parlez à son intelligence, BIEN). Si le client a effectivement tendance à vouloir inconsciemment réinventer les principes de l’ergonomie, quand ça n’est pas de la mécanique générale, à chaque étape d’un projet, on a aussi une fâcheuse propension à vouloir faire systématiquement le contraire de ce dont il a besoin (ou, au mieux, quelque chose dont il n’a pas vraiment besoin).

En bref, ce principe relève d’une méthodologie simple mais de bon aloi, que la sagesse populaire sait partiellement déjà formuler à sa façon (la paille dans l’œil du voisin et la poutre dans le chien, ou un truc approchant). Quand je vous dis que je suis sage, hein.