En résumé, l’industrialisation permet de dupliquer à grande échelle le produit conçu lors de la phase de création en s’assurant de sa qualité et en maîtrisant les coûts au plus juste, car l’ensemble de ses caractéristiques est connu précisément.

Or, n'en déplaise à certains, le développement logiciel est par essence une activité créative, au même titre que l’écriture d’un livre, la réalisation d’un dessin ou d’une peinture ou l’élaboration d’une nouvelle théorie mathématique.

En effet, si le programme existait déjà, personne ne demanderait à un développeur de l’écrire, donc de le créer…

La conception de logiciel ne peut donc être industrialisée puisque comme nous l’avons constaté précédemment, il est indispensable de disposer d’au moins un exemplaire physique pour pouvoir estimer précisément les ressources nécessaires à sa fabrication à grande échelle et avoir les informations nécessaires aux divers contrôles de qualité.

Il est donc très délicat sinon impossible d’estimer de manière fiable les ressources humaines, techniques et temporelles nécessaires à la conception d’un logiciel, et encore plus difficile de définir les spécifications permettant de s’assurer qu’il répond bien aux besoins.

J'en connais qui me rétorqueront qu’il est tout de même possible d’industrialiser à minima le développement d’un logiciel à l’aide de framework et autres briques logicielles « clef en main ».

Cependant, la colle nécessaire pour assembler ces briques afin d'obtenir le programme demandé devra être inventée et nécessitera donc toujours un effort créatif.

En conséquence, même en recourant à de tels outils, il reste impossible de donner une estimation précise et fiable du temps nécessaire à la réalisation d’un programme.

Car en réalité, les frameworks et autres briques logicielles ne permettent pas d’industrialiser le processus de développement d’un logiciel.

Ils facilitent uniquement la vie du développeur en lui permettant d’utiliser du code en théorie de bonne qualité, correctement documenté et conçu pour répondre aux besoins essentiels et communs à la plupart des programmes.

Évidemment, cela lui permet de développer plus rapidement son programme, mais ce n’est pas pour cela qu’il pourra estimer plus précisément le temps qu’il mettra à le concevoir dans son intégralité, d’autant que parfois, ces outils peuvent au contraire lui faire perdre du temps indépendamment de sa volonté.

De même, certains outils tels que les frameworks de tests unitaires ou fonctionnels ainsi que certaines méthodologies comme le TDD permettent effectivement d’estimer la qualité du code, tout comme les méthodes agiles permettent d’estimer le temps nécessaire à la réalisation d’un ensemble de tâches en se basant sur le temps passé précédemment pour réaliser d’autres tâches plus ou moins complexes.

Cependant, ces estimations sont empiriques et n’ont donc pas la précision absolue et intangible de celles ayant court dans le cadre d’un processus industrialisé.

En conclusion, demander à un développeur le temps qu’il mettra à développer un logiciel n’est pas la même chose que demander à un peintre en bâtiment le temps qu’il va mettre et le nombre de pots de peinture dont il aura besoin pour peindre un mur de 12 m² en vert.

Mona Lisa en ascii art

C’est en fait comme demander, s’ils étaient encore de ce monde, à Léonard de Vinci le temps qu’il va mettre à peindre le tableau d’une femme posant devant un paysage ou bien à Albert Einstein le temps qu’il lui faut pour inventer une théorie expliquant la relation entre l'espace, le temps, et peut être éventuellement d'autres paramêtres.

Et je suis prêt à parier que dans les deux cas, la réponse serait du style « un certain temps ».