Construire moins de projets, mais les rendre vraiment utiles

Un portfolio de développeur peut vite devenir une collection de projets créés pour montrer qu'on sait utiliser une technologie.

Ce n'est pas vraiment ce que je voulais pour Randy Code.

Au fil du temps, j'y ai ajouté des applications, des retours d'expérience et plusieurs outils destinés aux développeurs. Puis je me suis posé une autre question : qu'est-ce qui mérite réellement de devenir un projet open source autonome ?

C'est cette réflexion qui m'a amené à créer RepoCheckup, puis CookieCheckup.

Pas pour remplir mon profil GitHub. Plutôt pour construire moins de projets, mais faire en sorte que chacun ait une vraie raison d'exister.

Tout n'a pas besoin de devenir un projet

J'ai déjà construit plusieurs outils directement dans Randy Code.

InfraLens analyse une URL et remonte des informations sur les performances, la sécurité et la configuration technique d'un site. Cron Builder aide à composer et comprendre des expressions cron. JSON Studio permet de travailler rapidement avec du JSON. MetaLens se concentre sur les métadonnées d'une page, et API Studio permet de tester des requêtes HTTP depuis le navigateur.

Ils ne répondent pas tous au même besoin, mais ils partagent un point commun : ils ont du sens directement dans le portfolio.

Ils sont accessibles immédiatement, sans installation et sans compte. Ils enrichissent Randy Code au lieu de nécessiter chacun un nouveau produit, un domaine, une identité et toute l'infrastructure qui va avec.

C'est une distinction que je trouve de plus en plus importante.

Une idée n'a pas besoin de devenir un SaaS. Un petit outil n'a pas forcément besoin de son propre repository. Et un repository public n'a aucun intérêt simplement parce qu'il est public.

Le format doit venir du besoin, pas l'inverse.

Sortir du portfolio quand le projet le mérite

À un moment, continuer à ajouter tous mes outils dans Randy Code aurait aussi fini par créer l'effet inverse.

Certains projets peuvent être plus intéressants s'ils vivent indépendamment du portfolio : leur propre repository, une documentation dédiée, des releases et, lorsque c'est pertinent, leur propre mode de distribution.

C'est avec cette logique que j'ai créé RepoCheckup.

RepoCheckup est un CLI Node.js et TypeScript qui analyse rapidement un repository et signale différents points à vérifier dans sa configuration.

Le choix du CLI n'était pas seulement technique. C'était surtout le format naturel pour le problème.

Pas d'interface web à ouvrir. Pas de projet à uploader. Pas de compte à créer. L'outil s'exécute directement depuis le terminal, y compris avec npx repo-checkup.

Ça paraît assez simple une fois terminé. Mais publier un outil destiné à être utilisé par d'autres change beaucoup de choses.

Il faut penser à l'installation, aux messages d'erreur, à la sortie du terminal, à la documentation, aux versions, à la CI et au comportement de l'outil en dehors de son propre environnement de développement.

Le repository n'est plus seulement l'endroit où se trouve le code : il fait partie du produit. RepoCheckup est disponible sur GitHub et publié sur npm.

CookieCheckup : garder la logique, changer complètement le format

Après RepoCheckup, la solution facile aurait été de créer un deuxième CLI.

Puis un troisième.

Ce n'était pas le but.

Je voulais que mes projets open source soient complémentaires, pas simplement des variations autour du même exercice technique.

CookieCheckup part donc dans une direction différente.

C'est un outil web open source construit avec Next.js, React et TypeScript pour aider à vérifier, visualiser et comprendre le comportement des cookies dans un navigateur.

L'objectif n'est pas de scanner un site ou de remplacer les DevTools. On part d'une configuration de cookie et d'un contexte de navigation, puis l'outil explique ce que le navigateur devrait en faire : acceptation, stockage, correspondance avec un domaine ou un chemin, envoi dans une requête, accessibilité depuis JavaScript ou encore influence des attributs comme SameSite, Secure et HttpOnly.

Cette fois, une interface graphique apporte quelque chose que le terminal apporterait difficilement : voir le comportement et comprendre pourquoi il se produit.

RepoCheckup et CookieCheckup restent donc deux developer tools, mais ils n'essaient ni de résoudre le même problème ni de démontrer la même chose.

Et c'est volontaire. Le code de CookieCheckup est public sur GitHub.

Un GitHub public ne raconte pas forcément le travail réel

Il y avait aussi une raison plus personnelle derrière cette démarche.

Une grande partie de mes projets est privée.

C'est normal pour des applications personnelles, des produits en développement ou des projets qui n'ont simplement aucune raison d'être publics. Mais cela signifie aussi qu'un profil GitHub public peut donner une vision très partielle du travail réellement effectué.

La tentation serait alors de compenser en créant beaucoup de petits repositories publics.

Une application de tâches. Un clone d'un produit connu. Une démonstration d'authentification. Un projet créé principalement pour afficher une technologie supplémentaire sur un profil.

Je préfère l'approche inverse.

Quelques repositories publics, mais des projets que je peux réellement maintenir et assumer.

Un projet open source me semble beaucoup plus intéressant lorsqu'une personne extérieure peut comprendre pourquoi il existe, l'installer ou l'utiliser, lire sa documentation et éventuellement contribuer ou signaler un problème.

Le nombre de repositories devient secondaire.

L'open source impose une autre exigence

Le changement le plus intéressant n'est finalement pas de rendre le code visible.

C'est de développer en sachant que quelqu'un qui ne connaît ni le projet ni les décisions prises pendant sa création peut arriver dessus demain.

Des choses faciles à ignorer sur un projet personnel deviennent alors importantes :

• le README doit permettre de comprendre rapidement le projet ;
• l'installation doit fonctionner sans connaître mon environnement ;
• les erreurs doivent aider plutôt que simplement constater un échec ;
• les choix de configuration doivent être explicites ;
• les releases doivent être compréhensibles ;
• les contributions doivent pouvoir être accueillies proprement ;
• le repository doit rester lisible après plusieurs mois.

Ça oblige à regarder le projet autrement.

Et c'est probablement ce que je trouve le plus intéressant dans cette démarche : construire pour quelqu'un qu'on ne connaît pas encore.

Moins de projets, davantage de complémentarité

Je n'ai donc pas pour objectif de transformer mon GitHub en catalogue.

RepoCheckup couvre le CLI et l'écosystème Node.js/npm.

CookieCheckup explore davantage l'interface, React et le comportement du navigateur.

Les outils intégrés à Randy Code continuent, eux, à remplir un autre rôle : répondre rapidement à des besoins ciblés sans transformer chaque idée en projet indépendant.

Cette séparation me convient beaucoup mieux qu'une règle du type « tout doit être open source » ou, à l'inverse, « tout doit être intégré au portfolio ».

Certains projets doivent rester privés.

Certains petits outils fonctionnent mieux directement dans Randy Code.

Et certains méritent de devenir des projets open source autonomes.

L'important est surtout de savoir pourquoi.

Construire quelque chose qui mérite de rester

J'avais déjà commencé à suivre cette logique avec InfraLens : partir d'un besoin réel et construire l'outil que j'aurais aimé avoir sous la main.

RepoCheckup et CookieCheckup prolongent cette idée, mais en dehors du portfolio.

Je ne sais pas combien de projets open source viendront ensuite, et je préfère justement ne pas me fixer un nombre.

La contrainte que je veux garder est plus simple : un nouveau projet public doit apporter quelque chose que les précédents n'apportent pas déjà.

S'il n'y a pas de besoin, pas de différence intéressante ou pas l'envie de le maintenir, il n'a probablement pas besoin d'exister.

Construire moins laisse aussi plus de temps pour terminer, documenter, améliorer et maintenir ce qui existe déjà.

Et pour un projet open source, c'est peut-être finalement ce qui compte le plus.