Depuis les travaux sur la calculabilité dont on a reparlé récemment avec le film sur la vie d’Alan Turing, aucun résultat théorique d’ampleur n’est venu prendre la suite de ses travaux en matière de conception logicielle.
Cela a apparemment été difficile de convaincre de la possibilité de créer une machine, mais maintenant que cela fonctionne, la théorie a été abandonnée et aucune méthode logicielle n’est utilisée dans l’industrie.

Autant il existe une forme canonique pour une base de données avec Merise, autant un programme peut s’écrire d’autant de manières que l’on veut. Il existe bien des langages méthodologiques tels qu’UML, mais ceux-ci ne permettent en aucun cas de concevoir un logiciel étape par étape.
Le logiciel est donc dans cette contradiction de se vouloir être une industrie tandis que c’est du pur artisanat.
Les industriels, désormais beaucoup moins dirigés par des capitaines d’industrie que par des financiers, considèrent ainsi qu’il suffit d’allouer des équipes d’ingénieurs et que cela va se faire tout seul.

L’industrie, ce sont des cycles de développement très longs, typiquement de 15 ans, et le principal enjeu est en réalité de faire évoluer les logiciels plus que de les créer.
Cet enjeu de l’évolution des logiciels n’est pas considéré. Du tout. Et pourtant l’Informatique est une exception tandis que c’est un domaine où la conception pourrait évoluer très vite car le logiciel, n’est pas un matériel physique coûteux en ressources et main d’oeuvre, mais un contenu abstrait et malléable. Il n’est donc pas tiré parti de cette potentialité tout simplement parce que faire évoluer des conceptions en général subit la loi de mouvements conservateurs dont les enjeux politiques n’ont rien avoir avec ceux de la représentation.
Dans la réalité concrète, générer du code a donc très peu d’intérêt en égard à la capacité de faire évoluer un logiciel.
Des projets peuvent être paralysés quand bien même de forts enjeux économiques prévalent, et au bout de quelques mois de développement, jusqu’à 95% du temps employé par les équipes peut l’être sur des buts qui n’ont rien avoir avec les enjeux métiers spécifiques à l’industrie visée.

Cela donne une idée de la marge énorme d’amélioration du rendement à apporter dans le développement de logiciels. Dans de tels programmes en centaines de milliers de lignes de code, il faudrait pouvoir prendre des décisions rapidement, efficacement et savoir sur quels critères trancher entre plusieurs possibilités.
L’idée serait tout simplement d’exprimer à un niveau théorique les résultats validés par des expériences concrètes, d’aller beaucoup plus loin, et d’avoir les outils adéquats pour effectuer les travaux impliqués par des décisions sur la conception.
Il ne s’agit pas de rechercher le Graal en générant des logiciels à partir d’une expression de besoins, mais de travailler sur des enjeux d’évolution à la fois plus simples et beaucoup plus pertinents en égard aux besoins du monde du logiciel.
L’intérêt en est extrême d’un point de vue économique mais aussi dans notre manière d’appréhender en général les problèmes de conception sur le moyen et long terme afin de justifier les décisions prises à court terme.

Et cela aurait aussi un impact sur ces mouvements conservateurs qui bloquent plus généralement toutes les évolutions pour préserver leurs préorogatives, en explicitant à la fois des règles de conception ainsi que les détournements auxquels il faut veiller.