Projance Vigie : le code s’écrit comme un livre, et il mérite d’être relu

Cela fait 18 ans que je travaille dans le développement logiciel. 18 ans à écrire du code, mais surtout à en relire. À relire le code des autres, celui de mes collègues, de prestataires, et aussi le mien quelques mois plus tard.

Et à force de relire du code, on apprend à déceler assez vite les pratiques qui ne respectent pas les bonnes pratiques de développement.

Un peu borné sur la qualité du code

De mon côté, je l’avoue, je suis un peu borné sur la qualité du code. Sur la manière de l’écrire, aussi.

En développement, il existe des principes que la plupart des développeurs connaissent. DRY (« Don’t Repeat Yourself ») : ne pas recopier le même morceau de code à plusieurs endroits, parce que le jour où il faut le corriger, on en oublie forcément un. KISS (« Keep It Simple, Stupid ») : faire simple, tout simplement. Et SOLID, un ensemble de règles qui permettent de découper une application en morceaux qui ont chacun un rôle précis, pour pouvoir la faire évoluer sans tout casser.

Sur le papier, tout le monde est d’accord. Mais dans la réalité, quand la date de livraison approche, ce sont souvent les premières choses qu’on met de côté.

Écrire du code, c’est comme écrire un livre

Je considère qu’on écrit du code comme on écrit un livre.

Comme dans un roman, il faut que le code donne envie de le lire. Et surtout, il faut qu’il soit clair et compréhensible par tous.

Durant toutes ces années, j’ai toujours été focalisé sur le fait d’écrire du code clair : des variables bien nommées, des méthodes courtes et bien nommées. Pour que n’importe qui reprenne ce code, ou moi tout simplement plus tard, comprenne les choses. Et surtout, ait envie de relire ce code.

Un code lisible, clair, simple, ça donne envie d’y rentrer.

À l’inverse, un code où tout est mélangé, où les variables s’appellent tmp ou data2, personne n’a envie d’y toucher. Je repense encore à mon cher collègue qui avait pour habitude de nommer certaines variables « Robert » :-). Et un code auquel personne n’ose toucher, c’est un code qui coûte cher à chaque fois qu’il faut le faire évoluer.

Avec l’IA, tout le monde peut développer

Avec l’apparition de l’intelligence artificielle, les barrières pour faire du développement ont été rabaissées. Aujourd’hui, presque n’importe qui peut faire du développement assisté par l’IA.

C’est une bonne chose, j’en parlais d’ailleurs dans un article précédent.

Mais cela a un risque.

Des librairies avec des vulnérabilités, potentiellement utilisées sans le savoir. Du code pas forcément toujours bien écrit. Des failles directement dans le code. Et quand on n’est pas développeur, on ne les voit pas : l’application fonctionne, les premiers utilisateurs s’y connectent, et personne ne sait vraiment ce qu’il y a à l’intérieur.

Projance Vigie

C’est pour toutes ces raisons que j’ai doté la plateforme Projance d’un nouvel outil, nommé Projance Vigie.

L’idée est simple : faire ce que je fais depuis des années quand je relis du code, et le rendre accessible à tout le monde. Vous choisissez le dossier de votre code, Vigie l’analyse, et vous recevez un rapport en français simple. Pas de jargon à décoder.

Vigie regarde quatre choses.

Les librairies utilisées. Une application s’appuie en grande partie sur du code écrit par d’autres : on utilise une librairie plutôt que de réinventer l’envoi d’e-mails ou la gestion des paiements. Quand l’une d’elles a une faille connue, cette faille est publique, et n’importe qui peut l’exploiter contre votre site. Vigie repère les versions concernées et vous indique celle qui corrige le problème.

Les mots de passe et les clés oubliés. Une clé de paiement ou un mot de passe écrit en clair dans le code, ça arrive vite, souvent un soir de livraison pressée. Le problème, c’est que quiconque met la main sur le code met aussi la main sur la clé. Vigie vous dit dans quel fichier elle se trouve, sans la recopier dans le rapport.

Les failles dans le code. Injections, données affichées sans précaution, mode de débogage oublié en production. Ce sont des erreurs très courantes, et Vigie vous précise ce qu’il faut corriger.

La clarté du code. Vous l’aurez compris, c’est la partie qui me tient le plus à cœur. Code recopié à plusieurs endroits, méthodes trop longues ou trop compliquées : Vigie repère les endroits où les bonnes pratiques ne sont pas respectées, et leur donne une note à part, séparée de celle de la sécurité.

À quel moment s’en servir ?

Si vous êtes porteur de projet, par exemple quand votre prestataire vous livre une première version. Avant de payer le solde, vous lancez une analyse, et vous arrivez à la discussion avec des points précis plutôt qu’avec une impression. Ou quand vous reprenez un projet laissé par quelqu’un d’autre et que vous voulez savoir si la base est saine.

Si vous êtes prestataire, c’est l’occasion de trouver vous-même les oublis, avant que votre client ne tombe dessus.

Ce que Vigie ne remplace pas

Vigie ne remplace pas la relecture d’un développeur qui connaît votre métier et vos contraintes. C’est une première lecture, rapide et lisible, qui vous montre où regarder. Et si le rapport remonte des points sérieux, vous saurez au moins quoi demander.

Gratuit, avec un compte

L’analyse est gratuite. Il suffit d’avoir un compte Projance, porteur de projet ou prestataire, et vos rapports y restent : vous seul pouvez les lire.

Pour essayer, c’est sur la page de Projance Vigie. Et si vous n’avez pas encore de compte, vous pouvez le créer ici en quelques minutes.

Et si le rapport vous laisse avec des questions, c’est normal. C’est aussi à ça que sert Projance : décrire votre besoin, et trouver les bonnes compétences pour y répondre.