Un aspect souvent négligé dans les projets de développement logiciel est la phase de maintenance. Un projet est rarement vraiment terminé ; il continuera de nécessiter une quantité non nulle de travail au fil du temps. Dans la suite de ce texte, nous allons démystifier le pourquoi et le comment de cette phase.

Un peu de philosophie

On entend parfois dire que le code rouille, par analogie avec les matériaux utilisés dans le monde physique. Chez Thirdbridge, nous n'avons jamais vraiment aimé cette comparaison! Au contraire, le code source est un ensemble de commandes déterministes : exécuté dans les mêmes conditions, il produira le même résultat qu’il y a 50 ans!

C’est plutôt le monde extérieur qui évolue, rendant de plus en plus difficiles les interactions avec le code qui a cessé d’évoluer. Prenons l’exemple d’une faille de sécurité : elle n’est pas due à une dégradation du code, comme de l’acier qui s’oxyde. Au contraire, la faille de sécurité était présente dès le premier jour ; ce sont nos connaissances qui ont évolué. Le code, lui, est resté inchangé!

Plan de maintenance

Un plan de maintenance couvre habituellement trois facettes :

• La mise à jour des composantes principales et dépendances externes
• Les modifications résultant de facteurs externes
• Les modifications résultant de facteurs internes

Composantes principales et dépendances externes

Que ce soit la version du SDK Android pour une application mobile ou la version de Node.js pour un serveur web, l’écrasante majorité des projets numériques utilisent des composantes qui sont elles-mêmes en évolution. La majorité des projets utilisent aussi des dépendances externes qui nécessitent une attention particulière, car elles sont habituellement moins bien maintenues que les composantes principales.

Tenir ces composantes à jour est important pour deux raisons : la sécurité et la vélocité.

L’aspect de la sécurité est relativement simple à comprendre. Peu importe la technologie utilisée, aucune n’y échappe : de nouvelles failles sont constamment découvertes ! Avoir une cadence préétablie de mises à jour permet de réduire les chances d’utiliser une version vulnérable. Thirdbridge effectue également une vigie constante des failles de sécurité découvertes pour les différentes technologies utilisées dans nos projets. Nous pouvons ainsi prendre action rapidement et remédier à la situation avant qu’un acteur malveillant ne puisse exploiter la faille.

L’aspect de la vélocité est un peu plus abstrait. Si un projet n’est pas maintenu, la vitesse des développements futurs sera inévitablement ralentie. A court terme, l’impact est marginal, mais avec le temps, les développeurs seront de moins en moins efficaces.

Un excellent exemple, bien que quelque peu extrême, est celui du secteur bancaire. Aujourd’hui, les banques doivent débourser des sommes considérables pour embaucher des programmeurs maîtrisant le COBOL*. Pire encore, ces systèmes vieillissants sont mal adaptés aux nouvelles technologies, rendant toute tentative d’évolution particulièrement laborieuse. Soyons clairs : il faut des décennies pour en arriver à une situation aussi extrême ! Cependant, la régression de la vélocité commencera bien avant.

*Le langage COBOL a été conçu dans les années 1960 et il n’a pas suivi la même évolution technologique et les mêmes paradigmes de programmation modernes que les langages plus récents (gestion d’objets, développement web ou mobile, méthodologies agiles, etc.).

Facteurs externes

Parfois, des facteurs externes nous forcent à agir pour maintenir un projet à jour. Ces facteurs sont généralement très variés. Voici quelques exemples rencontrés chez Thirdbridge.

• AWS EKS facture 400 USD par mois si la version de Kubernetes n’est pas suffisamment à jour.
• À partir du 24 avril 2025, Apple refusera les applications qui n’utilisent pas iOS SDK 18.
• Avec la Loi 25, les entreprises québécoises ont dû mettre à jour leur site web pour y inclure une politique de confidentialité.

Facteurs internes

Dans d’autre circonstances, ce sont des facteurs internes qui nécessite des interventions sur un projet. Voici quelques exemples rencontrés chez Thirdbridge.

• Changement esthétique mineur sur un site web
• Modifications mineures de configurations internes d’un API Rest
• Modification des images de la page de présentation d’une application mobile sur le App Store

Montage financier

Chez Thirdbridge, le plan de maintenance prend la forme d’une banque d’heures annuelle non périssable. Comme les heures sont non périssables, elles permettent d’amortir la variabilité des demandes au fil des années. Sinon, les heures non dépensées peuvent être utilisées comme crédit pour des projets de développement futurs.

L’objectif est simple : offrir à nos clients la paix d’esprit et une stabilité dans leur flux de trésorerie. En effet, devoir débloquer un budget d’urgence pour régler une faille de sécurité n’est pas le genre d’expérience que Thirdbridge souhaite offrir.

L’importance du RSI

Le plan de maintenance n’est pas une carte blanche permettant aux développeurs d’essayer la dernière technologie à la mode tous les six mois. Il est important de considérer la stratégie future du projet lors de l’évaluation des efforts de maintenance.

Exemple tout frais : il y a moins d’un mois, React a annoncé la fin officielle de Create React App. Plusieurs de nos projets ont été bâtis avec cette technologie, mais pour certains de no s clients, effectuer une migration n’est même pas envisagé. La faible probabilité de développements futurs et le faible impact de potentiels enjeux de sécurité rendent tout simplement impossible la démonstration d’un potentiel retour sur investissement.

Conclusion

Un projet numérique est rarement complètement terminé. L’informatique évolue si rapidement que l’inaction peut avoir des impacts importants sur la sécurité et les développements futurs, et ce, après seulement quelques années. La mise en place d’un plan de maintenance est donc un point crucial — mais trop souvent négligé — pour tout projet numérique pérenne.

Avec notre approche de banque d’heures non périssables, nous offrons à nos clients non seulement la tranquillité d’esprit sur le plan technique, mais aussi sur le plan financier. La possibilité de reconduire les heures permet un flux de trésorerie stable, même si les besoins fluctuent au fil du temps.

Au-delà du code, la mission de Thirdbridge est d’offrir la meilleure expérience possible lors de la réalisation de projets numériques, et nous sommes convaincus que notre plan de maintenance est un élément clé pour y parvenir.