Si t’es pas codeur, t’es pas producteur de logiciels

Au fil de ses réflexions sur le livre numérique, Thierry Crouzet vient d'écrire deux billets Si t’es pas codeur, t’es pas auteur et T’es pas codeur, t’es pas éditeur.

Je ne connais rien, ou si peu, au livre numérique mais quelques passages m'ont fait l'effet d'une étincelle.

Un auteur numérique ne produit pas des textes figés. Il doit rester en éveil sur ses créations, les faire vivre, leur donner la possibilité d’évoluer, sans pour autant renoncer à les partager avec ses lecteurs. C’est aussi une dimension de l’écriture qui a été peu exploitée jusqu’ici, à cause de la lourdeur des procédés éditoriaux.

S’il faut deux jours pour créer un epub, vous pouvez parier qu’aucun éditeur ne s’amusera à le recréer chaque fois que l’auteur en exprimera le souhait. Si tel est le cas, il ne fait que mimer en numérique l’édition papier.

Ces passages s'appliquent quasiment mot pour mot à la production de logiciels.

Un producteur de logiciels ne fabrique pas des oeuvres figées. Il doit rester en éveil sur ses créations, les faire vivre, leur donner la possibilité d’évoluer, sans pour autant renoncer à les partager immédiatement avec ses utilisateurs. C’est aussi une dimension de la production de logiciels qui a été peu exploitée jusqu’ici, à cause de la lourdeur des procédés de spécification, conception, distribution et installation.

S’il faut deux mois pour vérifier, valider et déployer une nouvelle version de logiciel, vous pouvez parier qu’aucun producteur ne s’amusera à dérouler toutes ces étapes chaque fois que l'utilisateur en exprimera le besoin. Si tel est le cas, il ne fait que mimer en numérique la création de produits physiques.

La production de logiciels telle que pratiquée par la majorité des "professionnels" a quelque chose d'assez déroutant : le produit réalisé et fourni à des utilisateurs est exclusivement immatériel mais les procédés qui encadrent sa réalisation sont la plupart du temps hérités du monde matériel.
Les éditeurs de livres dont parle Thierry Crouzet ont un très probablement un chemin à parcourir pour intégrer dans leurs pratiques quotidiennes la notion de "code" qui vient naturellement avec le passage au numérique. Les producteurs de logiciels, malgré la présence du numérique inhérente à leur activité, ont exactement le même problème.

Pourquoi ? Parce que la plupart d'entre eux ne sont pas des codeurs.

Oh... Il y a bien évidemment dans une équipe de production de logiciels quelques personnes capables d'écrire du code... sinon le logiciel ne verrait bien évidemment jamais le jour. Mais la production ne s'arrête pas à cela. On y trouve aussi des analystes capables de décrire le besoin des utilisateurs, des testeurs pour vérifier le bon comportement du logiciel, des auteurs techniques pour écrire les manuels d'utilisation et bien d'autres rôles. Sans oublier l'incontournable chef de projet qui dirige tout ça.
Tous ces rôles sont essentiels [1] mais ils sont souvent occupés par des personnes pour qui l'écriture de code n'est pas une activité naturelle et qui n'ont donc pas le réflexe d'introduire la notion de code au coeur du procédé de fabrication.

La conséquence directe c'est que pour produire un logiciel, une équipe se retrouve à faire nombre d'activités manuelles.
La conséquence suivante, c'est que pour gérer l'enchainement de ces activités manuelles, le chef organise l'activité de production comme un projet[2].
Un "projet", c'est un truc qui a un début et une fin et diverses phases qui ne sont justifiées que par l'impossibilité matérielle de réaliser toutes les activités manuelles en même temps.

Les vendeurs d'outils[3] pour la production de logiciel ne sont pas étrangers à cette situation. Les producteurs de logiciel, en utilisant ces outils, s'éloignent du code utilisé pour fabriquer le logiciel. Ils laissent le soin à d'autres de définir ce code à leur place et se retrouvent ainsi à ne maitriser que vaguement leur processus de fabrication dont ils bouchent les trous à grand renfort de procédures manuelles.

Mais cela n'a rien d'une fatalité.
Il faut simplement oser sortir de la logique de projet pour entrer dans une logique de flux. Le code est la clef de cette transition. En s'appropriant le procédé de fabrication et en l'automatisant soi-même[4] sous forme de code, chaque équipe de production de logiciel peut s'affranchir de nombreuses contraintes physiques. Tout ce qui constitue un goulot d'étranglement à l'écoulement du flot de fonctionnalités vers l'utilisateur doit être soigneusement éradiqué en introduisant le code adéquat[5].

Les méthodes agiles, en mettant en avant les cycles courts et la production en continu, favorisent l'émergence d'une telle logique de flux.

Notes

[1] quoique, pour le chef de projet, ça se discute

[2] d'où son nom : chef de "projet"

[3] outil pris au sens large : IDE, compilateur, debugger, contrôle de code source, gestion d'exigences, gestion de défauts, ...

[4] il faut certes avoir recours à quelques outils mais, des outils dont on garde l'entière maitrise tel un artisan dans son atelier.

[5] je ne dis pas que tout le monde dans l'équipe doit apprendre des techniques de codage mais tout le monde devrait, au minimum, voir les choses avec les yeux d'un codeur

Luc

ba on s'en fou de produire des logiciels ce qui est important c'est de rendre des données accessibles, genre on arrête de faire des moissonneuses batteuses avec lecteurs MP3 et on aide le mec qui délivre le service (l'exploitant) à mieux le faire :)

Luc 31 mars 2011 - 21:20
Oaz

Luc, je ne crois pas avoir compris le sens de ta remarque...

Ne sachant pas encore fabriquer de baguettes magiques, ce que j'ai trouvé de mieux jusqu'à présent pour "rendre des données accessibles", c'est de faire un logiciel.

Oaz 31 mars 2011 - 21:43

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.