Les logiciels derrière vos sites clients reçoivent-ils encore des correctifs de sécurité ?

Parmi les sites que vous maintenez, combien tournent sur des logiciels qui reçoivent encore des correctifs de sécurité ? Mieux vaut le savoir avant qu’un client ne le demande.

« Sont-ils à jour » est une autre question, plus douce. Celle-ci est plus étroite. Quand une faille tombera dans PHP le mois prochain, un correctif existera-t-il pour la version sur laquelle tourne ce site, ou cette version a-t-elle été abandonnée par ceux qui l’ont écrite ?

La plupart des agences ne savent pas répondre, et ce n’est pas de la négligence. Répondre à la main veut dire ouvrir chaque compte d’hébergement, relever le runtime de chaque site, puis comparer chacun d’eux à un calendrier de support qui bouge à mesure que les versions vieillissent. C’est un après-midi de travail qui est périmé la semaine suivante, donc personne ne le fait deux fois.

Pourquoi la réponse dépasse PHP

Le runtime est la partie évidente. C’est aussi la partie qui vous flatte, parce qu’un site sur un PHP supporté donne un sentiment de sécurité.

Un projet Laravel embarque des dizaines de composants Symfony en dessous, et ceux-ci ont leurs propres cycles de vie qui se terminent à leurs propres dates. Les paquets que vous avez ajoutés il y a trois ans et jamais rouverts aussi. Un projet peut reposer sur un Laravel parfaitement supporté et dépendre quand même d’une série de composants qui ne reçoit plus de correctifs depuis des mois. « Nous sommes sur un Laravel supporté » n’est pas toute la réponse, c’en est la première ligne.

L’inverse est vrai aussi. Un site peut tourner sur un PHP mort pendant un an sans le moindre symptôme, parce que rien ne casse quand le support s’arrête. Il ne se passe rien du tout, et c’est bien le problème.

À quoi la réponse doit ressembler

Pour être utile plutôt qu’angoissante, elle doit arriver dans une forme précise.

Elle doit être par projet, parce que c’est comme ça que vous facturez et que vous menez la conversation. Elle doit nommer la date où le support s’est arrêté ou s’arrêtera, pour que « vieux » devienne quelque chose que vous pouvez écrire à un client. Savoir que PHP 8.1 est terminé n’est que la moitié d’une décision, donc elle doit aussi dire vers quoi aller. Et elle doit se mettre à jour toute seule, parce que la raison pour laquelle personne ne fait ça à la main, c’est que la réponse périme.

Ce dernier point pèse plus lourd qu’il n’en a l’air. Une version meurt quand une date passe, qu’on ait déployé ou non, donc tout système qui ne s’en aperçoit qu’au déploiement vous dira qu’un site va bien jusqu’au moment où quelqu’un y touche.

Ce que cela change avec les clients

La conversation inconfortable sur le forfait de maintenance se passe mal parce que les deux camps discutent d’une impression. L’agence sent que le travail est réel. Le client voit une ligne sur une facture et un site identique au mois dernier.

Une liste des sites de ce client, avec les logiciels derrière chacun et la date à laquelle chacun cesse de recevoir des correctifs de sécurité, change le sujet de la discussion. Vous ne défendez plus un tarif. Vous montrez un calendrier, et ce calendrier porte des dates qui arriveront que quelqu’un agisse ou non. Certaines tombent au trimestre prochain. C’est ça, la conversation.

Cela change aussi ce que vous héritez. Quand un site arrive d’une autre agence, la première question honnête est de savoir ce qui tourne réellement dessous, et la seconde combien de temps il lui reste. Les deux ont une réponse dès le premier jour au lieu d’après le premier incident.

Dans Unolia, cela vit dans l’espace Versions d’un projet : ce que chaque projet exécute, ce qu’il publie, et où chaque version se situe par rapport aux fenêtres de support publiées par ceux qui la maintiennent. Un runtime en fin de vie cesse d’être un badge et devient un problème sur le projet, donc il apparaît le matin à côté de tout ce qui demande une décision.