En réalité, une application web n’est pas très différente d’une voiture. Imaginons que vous soyez sur la route, et que vous remarquiez que vous n’avez presque plus d’essence. Si vous ne faites pas le plein, votre voiture tombera inévitablement en panne et ne fonctionnera plus.
De même, si une pièce de votre véhicule venait à rendre l’âme et que plus personne ne la fabriquait, vous devrez remiser votre voiture au garage. C’est d’ailleurs tout le principe de l’obsolescence programmée, qui consiste à atteindre volontairement cette situation pour accélérer le renouvellement des produits.
Pour une application web, c’est assez similaire. Certes le code ne s’use pas, mais à l’instar d’une réparation sur une voiture, il y a de fortes chances que vous soyez dans l’obligation de modifier votre application à un moment ou à un autre pour :
Quand le moment sera venu de modifier votre application, il est possible que les dépendances sur lesquelles s’appuie celle-ci ne soient :
Or, une application a toujours besoin de dépendances pour fonctionner, que ce soit le code d’un plug-in, un langage, un framework, ou encore, une base de données.
Par ailleurs, une application fonctionne rarement en vase clos. Elle fait partie d’un écosystème : soit elle utilise un SSO pour s’authentifier, soit elle fait par exemple appel aux API d’un autre système. Ces systèmes tiers sont eux aussi vivants et impliquent que l’on s’y adapte pour pouvoir continuer à les utiliser.
Ce qui complique la maintenance d’une application, c’est donc bien cet écosystème mouvant : dans les dépendances, les systèmes tiers et les standards. Ces derniers évoluent eux aussi, et beaucoup plus vite que dans le monde « réel ».
Imaginez qu’un an après avoir acheté votre voiture, un nouveau système de pompes à essence voit le jour et devient le nouveau standard. Il existerait donc deux types de pompes à essence : celles qui fonctionnent avec votre véhicule, et les autres. Si le nouveau système, jugé plus efficace, remplace progressivement l’ancien, qu’allez vous faire ?
C'est à ce type de questions, adaptées aux numériques, qu'un audit va permettre de répondre.
Un audit permet de mesurer l'adéquation entre les technologies utilisées par l'application et l'état du marché afin de déterminer la meilleure manière de continuer à faire évoluer le produit.
L'application que vous utilisez a été écrite par des humains (si vous ne me lisez pas en 2040), qui ont des compétences spécifiques. Pour que votre application puisse évoluer, il faut qu'il y ait des gens disposant des compétences nécessaires. C'est tout aussi vrai pour votre voiture et votre garagiste. Il est donc important de vérifier régulièrement que l'application et ses dépendances soient maintenues, mais également maintenables.
C'est d'autant plus critique si une application est conséquente. En effet, certaines applications sont trop conséquentes pour qu'une seule personne puisse la connaître et intervenir dessus. Votre garagiste peut sans doute comprendre et intervenir sur l'ensemble de votre voiture mais certainement pas sur une fusée. Il faut donc vous assurer que les N compétences nécessaires pour faire tourner votre application soient encore disponibles.
À l'inverse il faut également mesurer le facteur d'autobus. Vous savez, cette personne qui a développé plus de 80% de l'application seule et qui en connaît tous les rouages. Qu'adviendra t-il quand elle ne sera plus disponible ?
Un audit permet d'évaluer la correspondance entre les compétences nécessaires pour faire fonctionner votre application et les compétences disponibles. Il permet de mesurer également la dépendance à une ou quelques personnes, et le risque associé.
La sécurité est un bon exemple de facteur mouvant. De nouvelles failles de sécurité sont sans cesse découvertes et peuvent survenir à tous les étages de votre application : code développé en interne, code d'une dépendance, faille d'un protocole. Les dépendances et systèmes tiers avec lesquels votre application interagit sont sans cesse mis à jour et impliquent que vous fassiez le nécessaire de votre côté pour utiliser les versions corrigées.
Les systèmes qui sont massivement utilisés (base de données, OS) publient généralement un calendrier pendant lequel ils s'engagent à maintenir une version donnée de leur logiciel. C'est par exemple le cas sur la page de versioning de postgresql.
Cela signifie que passé une certaine date, la version correspondante du produit ne reçoit plus de mise à jour ni de correctif de sécurité. Vous devez donc obligatoirement monter de version majeure pour bénéficier des correctifs. Or, une montée de version majeure engendre de potentiels changements dans l'utilisation de certaines fonctionnalités, voire, des retraits de ces fonctionnalités. À une très large échelle, on peut citer l'exemple de Windows XP dont la fin de vie a été maintes fois repoussée car énormément de systèmes reposaient sur cette version.
Si vous tardez trop et n'anticipez pas ces changements, vous devrez donc choisir entre la peste et le choléra : soit une application vulnérable (de par la vulnérabilité de sa dépendance), soit une application dont certaines fonctionnalités ne fonctionnent plus (car s'appuyant sur des fonctionnalités retirées ou modifiées de ladite dépendance).
La base de données est un exemple, mais toutes les dépendances sont soumises aux mêmes effets, aussi bien pour le code que l'infrastructure. La principale différence entre ces dépendances tient du fait que certaines ne disposent même pas de ces calendriers offrant une visibilité sur la fenêtre de maintenance des différentes versions. Des dépendances très largement utilisées (souvenons-nous d'Heartbleed pour OpenSSL) sont parfois maintenues par une poignée de volontaires de façon complètement bénévole et sans calendrier officiel.
Les failles de sécurité ne viennent pas que de l'extérieur, et il est important de s'assurer que le code de l'application en tant que tel n'est pas exposé (XSS, CSRF, injections SQL, protocoles).
Un audit applicatif permet d'évaluer la sécurité d'une application et de ces dépendances. Le calendrier de maintenance des dépendances doit être analysé pour proposer une plan de montée de version cohérent.
Si votre application passe déjà tous ces premiers points de contrôle, c'est une très bonne chose. Cependant, il reste un point tout aussi important : l'organisation et les processus permettant d'intervenir sur l'application.
Dans un premier temps, il est nécessaire de regarder comment l'application est façonnée et organisée. Concrètement, il s'agit de déterminer le niveau de complexité quand l’application va commencer à être détricotée : faut-il 2 jours ou 2 heures pour comprendre comment fonctionne n'importe quelle fonctionnalité ?
Ce point est très sensible, car il peut parfois venir s’opposer à la qualité. En effet, certaines équipes prophétisent un découpage extrême du code au motif impérieux de la qualité. Ce qu'on ne peut pas renier : chaque partie est proprement découpée, testable en isolation, mais cela se fait au détriment de la réconciliation de l'ensemble et de sa compréhension. Or, si la moindre intervention sur votre application prend cinq jours, on peut peut-être parler de qualité, mais pas de maintenabilité.
L'audit de code doit permettre d'évaluer le juste niveau de qualité.
Les processus et l'organisation sont tout aussi importants pour garantir la maintenabilité de l'application. Posez-vous la question suivante : le développeur qui rentre sur le projet peut-il rapidement être autonome sur l'application car correctement guidé par les processus en place ?
Comprendre comment est développée une fonctionnalité revient à suivre le câble. On préférera nettement la situation de droite.
Les processus regroupent aussi bien la documentation en place, que le chemin à parcourir pour aller livrer le code en production. Il est préférable que chaque livrable ajoute la valeur souhaitée à l'application sans nuire à sa sécurité et sa maintenabilité. Cela peut passer par des processus humains (relecture de code) et automatisés (intégration continue).
L'audit permet d'évaluer la complexité pour un nouvel entrant sur le projet de devenir rapidement autonome ou non, ainsi que les garanties offertes par les processus contre les régressions.
Ces processus doivent accompagner aussi bien le développement que la livraison de correctif, pour éviter qu'une correction de bug en production ne ressemble à ça :
Un audit permet d'évaluer la fiabilité des processus de développement et de déploiement, afin de limiter les régressions. Il analyse également la facilité de mise en production et de retour en arrière (rollback).
Le nombre de points à couvrir dans un audit est assez important et ceux-ci doivent être réalisés régulièrement. L'intérêt majeur est d'avoir une visibilité claire sur la situation afin d'être en mesure d'anticiper les décisions, plutôt que d'avoir à les prendre en étant au pied du mur.
