# uname -a

Le travail de l’architecte

Le fond du problème c’est qu’écrire un logiciel est un exercice aussi compliqué que rédiger une démonstration mathématique. C’est vrai pour tout logiciel, qu’il s’agisse d’une interface Web avec des boutons colorés de partout, ou d’un contrôleur robotique avec interpolation de mouvements.

Écrire un logiciel logiciel c’est d’abord formaliser un problème, le décrire totalement, en apprivoiser tous les contours pour en voir la forme. Quand on a l’aspect général, on peut commencer à construire la structure qui servira de base pour tisser le reste du programme. La phase de compréhension du problème est cruciale : mieux elle est faite, plus les choses seront faciles. Il ne doit pas rester un seul point de doute, au risque de remettre en cause la structure. C’est très difficile de changer une table basse en armoire, pourtant à la base c’est la même chose : c’est des planches de bois, non ?

Une maison “vivante”

La base du logiciel, c’est le code source. Du moins, pour ce qui est de le faire exécuter sur un ordinateur. Mais un logiciel c’est pas juste du code, c’est surtout des idées, des principes, des mécanismes, des flux, des signaux, des “choses qui bougent” à l’intérieur au moment de l’exécution. Le code n’est que le support, la matrice sur laquelle vont naviguer les informations. Le travail de l’informaticien c’est de réaliser cette matrice, mais surtout de la rendre utilisable et compréhensible pour d’autres. La question qu’on se pose quand on écrit un logiciel c’est “comment”, celle quand on lit un logiciel c’est “pourquoi”.

Reprendre un logiciel existant pour lequel il n’y a pas de documentation, c’est arriver dans une cathédrale, et essayer de retrouver les murs porteurs sans l’aide de plans. Ensuite il faut arriver à rajouter un étage sans que la toiture s’effondre, tout ça bien sûr en respectant scrupuleusement la forme originale du bâtiment, les matériaux d’origine, et les techniques précédemment utilisées.

Une maison modulable

Source de l’image : monmacon.tumblr.com

Une autre chose que les gens ne comprennent pas vis à vis des logiciels, c’est que l’on ne crée pas un logiciel comme on crée un objet. Un objet a nécessairement une utilité et un périmètre d’utilisation fixe et définitif lorsqu’il est terminé. Une salière pourra devenir une sucrière, mais globalement on ne s’en servira pas d’arrosoir. Pourtant dans le fond c’est pareil, c’est un réservoir avec grille trouée posée dessus, non ? Un logiciel par contre devra évoluer, s’adapter aux autres logiciels qui changent autour de lui, ou aux besoins des utilisateurs qui changent avec le temps.

Cela explique que les logiciels sont composés à 30% de code pour répondre au besoin actuel, et à 70% de code prévu pour les besoins futurs. Tous les outils de développement, les mécanismes de création d’interfaces, les APIs, toutes ces “couches” logicielles contiennent environ 80% de code qui ne sera pas utilisé, mais qui est là pour prévoir l’utilisation que l’on pourrait en faire.

Oui, avec certains outils logiciels (frameworks), on peut écrire très rapidement un logiciel qui répond à un besoin simple et précis, tout est pratiquement déjà fait. Mais s’il est construit trop vite, il sera alors difficile de de faire évoluer, le réparer, assurer sa maintenance, ou même arriver à le réécrire entièrement en conservant les données qui y ont déjà été saisies. C’est pour ça que les programmes complexes “rament”, ils sont construits avec des couches et des couches de fragments qui ont été rajoutés à parti d’une idée simple, sans avoir eu la réflexion global sur le pourquoi et le comment. N’oubliez pas que les logiciels que vous achetez sont souvent vendus “en l’état”.

De leur côté, les clients veulent juste “que ça marche”, mais un bâtiment que l’on voit terminé dès la première phase de conception, c’est une maquette, on ne peut pas s’en servir comme habitation. Pourquoi quand il s’agit d’informatique les clients ont pris l’habitude d’habiter dans des maisons en cartons ? Pourquoi crier quand la maison s’effondre à la première pluie, plutôt que de se demander pourquoi on n’a pas écouté l’architecte qui vous a dit qu’habiter dans du carton ça allait vous poser des problèmes ?

C’est vrai il existe le phénomène inverse. Certains clients habitent dans des maisons en béton armé, fruit de plusieurs d’années d’études et de construction, et ne comprennent pas pourquoi il est si difficile d’ajouter une nouvelle pièce, surtout quand leur voisin qui a une maison en bois a terminé ses travaux d’extension en un temps record.

Quand t’as pas de Ferrari, t’as une Logan

Une autre chose que les clients ne comprennent pas, c’est que créer un système logiciel entier à partir de rien est un millier de fois plus compliqué que d’assembler des briques existantes. Le problème vient alors de la connaissance des briques, qui fait souvent défaut, et qui ramène au cas précédent : on fait trop vite avec des outils que l’on ne maîtrise pas.

Dans la majorité des cas, les informaticiens qui sortent des écoles ont surtout appris à écrire du code. À partir de ce constat, il serait illusoire de vouloir leur faire réécrire des concepts qui fonctionnent déjà très bien dans des briques de base, au risque de leur faire inventer la roue carrée.

Si vous avez les moyen de vous payer des ingénieurs-enseignants-chercheurs en informatique, alors oui vous pouvez construire votre Ferrari logicielle sur mesure. Sinon, embauchez simplement des ingénieurs en informatique, ils vous feront une Logan logicielle, en utilisant les outils inventés par les ingénieurs-enseignant-chercheurs (moteur, autoradio, carrosserie). Utilisez des solutions génériques, ne demandez pas à vos ingénieurs d’inventer le moteur à eau.

Vous travaillez sur et avec de l’humain

Source de l’image : monmacon.tumblr.com

N’oubliez jamais que derrière votre jolie interface que vous avez imaginée vous-même il y a des êtres humains. Les êtres humains sont par nature faillibles, ils sont sensibles au stress, ainsi qu’à la fatigue.

Contrairement à un travail à la chaîne ou un travail de manoeuvre, la conception logicielle requiert une attention continue pendant plusieurs heures, une baisse de l’attention produira un bug.

Lorsque l’on compresse les coûts de développement, on n’a que deux variables d’ajustement : le salaire de l’ingénieur, et son temps de travail. À partir de ce concept est né l’unité jour-homme, on donne un prix fixe pour une journée de travail, et le reste c’est du temps nécessaire à la tâche qui est facturé en multipliant le coût journalier par le nombre de personnes qui travaillent, et par le nombre de jours travaillé.

Mais de la même manière qu’on ne peut pas avoir un enfant en un mois, même en demandant à neuf femmes de regrouper leurs efforts, les coûts de travail ne sont pas linéaires lorsqu’on travaille en groupe : deux personnes ne vont pas deux fois plus vite, au mieux elles vont 1,8 fois plus vite. Vendre en jours-homme est une erreur encore lus flagrante en informatique, si on considère que le coût nécessaire pour assembler le travail réalisé par deux personnes sur un même logiciel est parfois supérieur au coût dépensé par les deux personnes.

Vendre au nombre de jours un logiciel est une erreur : en informatique on peut garantir les délais, on peut garantir les fonctionnalités, mais on ne peut pas garantir les deux. Toute tentative de mettre un ensemble de fonctionnalités facturées à l’unité dans un grand budget de plusieurs jour échouera avec une probabilité de retard proportionnel au temps donné pour le projet. Pour peu que le client pressé veuille une livraison partielle et décide que “telle fonctionnalité n’est pas prioritaire, faites moi celle-ci à la place” : le client vient de faire tomber le château de cartes, il faut réécrire une partie du logiciel. Si on ne réécrit pas tout (on ne le fait jamais), on fragilise la cohérence de l’ensemble. Si on avait prévu que le client change d’avis, alors on a dépensé du budget de développement potentiellement en pure perte. Donc on facture plus cher, au cas où.

Chaque logiciel est unique

Un logiciel est une création originale. À partir de là, deux logiciels ne se ressembleront pas, même si tous les efforts ont été fait pour que cela soit le cas. S’ils étaient strictement identiques, alors il n’y en aurait qu’un seul.

Un logiciel, contrairement à un pont ou une voiture, c’est différent non pas seulement dans ce que l’on voit mais aussi dans toute la technique qui est derrière, et qui est unique pour chaque logiciel. C’est comme si vous demandiez une création originale, du moteur jusqu’aux jantes, et donc vous allez avoir besoin d’apprendre à l’utiliser.

Peut importe quel type de logiciel vous demandez, peut importe que les interfaces aient été décrites à l’avance, peut importe l’anticipation que vous en faites : vous allez avoir besoin d’apprendre à l’utiliser. C’est à la fois stressant pour les utilisateurs à qui on n’a pas donné le temps de monter en compétences sur le logiciel, et les concepteurs du logiciel à qui on demande après la livraison de “refaire comme le logiciel faisait avant”, en bref ré-implémenter une fonction obsolète dans un logiciel neuf.

Les coûts liés à la conception d’un nouveau logiciel sont souvent sous-évalués car ils ne prennent justement pas en compte les temps de formation, et de rédaction des documentation, pourtant indispensables pour utiliser efficacement le logiciel.

Conclusions

Source de l’image : monmacon.tumblr.com

L’informatique est aussi difficile que l’ingénierie et difficile. Avec un handicap supplémentaire sur le fait que les méthodes et les processus de fabrication des logiciels ne sont pas encore éprouvés au niveau des méthodes de l’ingénierie civile.

La majorité des clients et des utilisateurs ont une vision tellement déformée de l’informatique qu’ils font de mauvais choix, ou exigent des choses impossibles.

S’il est difficile de construire un logiciel, il est difficile aussi pour le client de savoir à quoi s’attendre au milieu des réponses à son appel d’offre. Le fossé entre les techniciens et les clients ne pourra se faire que par une sensibilisation du client aux impératifs du logiciel. Le mécanisme MOA/MOE peut dans certains cas aider à améliorer cet état de fait, à condition que les différents interlocuteurs s’écoutent, respectent leurs décisions respectives, et soient composées de gens compétents.

Dans un logiciel, on ne paie pas juste le type qui va écrire des lignes de code au kilomètre, on paie aussi (et surtout) pour ceux qui vont définir ce que va être le logiciel, qui vont réaliser l’intégration du logiciel, les tests de qualité, la maintenance, la formation des utilisateurs. Un logiciel est fondamentalement plus un service qu’un produit.