Au moment de la grande peur du bug de l’an 2000, de nombreuses entreprises se sont aperçues qu’elles utilisaient des programmes écrits 20 ou 30 ans auparavant. Leurs auteurs avaient quitté l’entreprise depuis longtemps, l’entreprise elle-même avait plusieurs fois changé de nom, de locaux, de propriétaire. Les logiciels, l’immatériel durent souvent plus que le matériel.
Si nos programmes avaient la solidité du théorème de Pythagore, on ne pourrait que se réjouir de cette pérennité mais entre bugs et adaptation à une réalité changeante, il faut constamment remettre une partie de l’ouvrage sur le métier. Avec plus ou moins de difficultés. Les coûts dus à ces difficultés sont les intérêts sur ce que l’on appelle la dette technique*.
La dette sera d’autant plus importante et ses intérêts coûteux que, souvent pour aller plus vite initialement, on aura négligé :
- la précision des concepts utilisés et leurs liens,
- l’architecture logicielle, la modularité
- le respect des règles de codage en particulier des commentaires clairs et complets
- la documentation
- la mise en place d’une base suffisamment couvrante de tests automatiques
- …
Ces causes semblent porter en elles leurs remèdes : bien définir les concepts, respect des règles, etc. Mais ces remèdes n’en sont que si ceux à qui ils s’adressent en sont les acteurs convaincus. Que son code, sa librairie, son logiciel puisse être repris facilement par un autre, c’est accepter, au sens étymologique, l’aliénation, accepter que l’œuvre échappe à son créateur. D’où une forte résistance à l’application des bonnes pratiques et l’inflation de la dette technique.
Une des raisons d’être d’une Scop est de maitriser collectivement, autant que faire se peut, son destin professionnel : élection de la direction, partage des décisions stratégiques, de l’organisation, des bénéfices… pas de délocalisation, de changement de propriétaire pendant le week-end, de fonds de pension qui vident les réserves ou simplement des décisions qui te concernent au premier chef et sur lesquelles tu n’as rien à dire. Dans la Scop, partager son code va normalement avec les autres partages et le très faible turn-over (devinez pourquoi ?) renforce les raisons d’avoir une faible dette technique.
A dire vrai, dans Alma, elle n’est pas si faible que ça, car, dans nos gènes, il y a aussi la grande autonomie dont chacun bénéficie et l’attachement fort au produit de son travail.
Ce sont aussi nos contradictions qui nous font vivre.
Une réponse
Je me permets de répondre à votre article pour vous pointer un de nos ouvrages, La Dette Technique (http://t13h37.fr/livre-dette-tech), qui devrait vous intéresser.
Nous sommes un petit éditeur indépendant et nous sommes également en pleine campagne de financement participatif (http://t13h37.fr/kickstarter/) afin de faire imprimer ce livre (et un autre), car ils n’existent aujourd’hui qu’en version numérique.
Les commentaires sont fermés.