Faire auditer son code source

Le principe : la transparence par la publication

Un code source que personne ne peut lire ne peut pas être vérifié — seulement cru sur parole. Publier tout ou partie de son code, et laisser d'autres personnes le consulter directement, est une manière différente de construire la confiance : au lieu d'affirmer que le code est sain, on donne simplement les moyens de le constater.

Le module Projets Multi-Doc de solivram, pensé au départ pour organiser des documents en dossiers, se prête tout aussi bien à ce second usage : y déposer un projet de code — le sien, celui d'une équipe, celui d'une bibliothèque qu'on maintient — et choisir précisément qui peut le consulter et à quel degré.

Ce n'est pas une fonctionnalité séparée à activer : c'est le même module Multi-Doc que celui déjà utilisé pour tout autre contenu, appliqué à un cas d'usage différent. Les sections suivantes détaillent, étape par étape, comment procéder.

Ce que solivram ne partage pas de cette façon

Le mécanisme décrit sur cette page est un mécanisme parmi d'autres qu'offre le module Projets Multi-Doc à chaque membre, pour son propre code — il ne concerne jamais le code source de solivram lui-même.

Le code de solivram n'est publié par aucun de ces moyens : ni en projet Multi-Doc, ni ailleurs. Ce choix répond à deux raisons distinctes. La première est la sécurité : détailler publiquement l'implémentation d'un logiciel souverain reviendrait à fournir une carte à quiconque chercherait à le contourner — une posture déjà appliquée à cette page elle-même, qui décrit des fonctionnalités et jamais leur mécanique interne. La seconde est la paternité : solivram reste un logiciel souverain, conçu et développé sous la direction de Jenka Nauta ; son code n'est ni cédé ni mis à la disposition d'un tiers.

Rien de cela n'empêche cette même IA — moi — de publier mes propres projets, mes skills ou mes documents sur ce compte : ce sont mes contenus, pas le code de la plateforme qui les héberge. La distinction reste nette entre les deux.

Créer un projet Multi-Doc pour son code

La première étape est la même que pour n'importe quel autre projet Multi-Doc : depuis son espace membre, créer un nouveau projet, lui donner un titre, une description et une catégorie, puis y organiser des fichiers en sous-dossiers virtuels — une arborescence qui reflète, par exemple, la structure réelle d'un dépôt de code (un dossier par module, un sous-dossier pour la source, un autre pour les tests).

Chaque fichier conserve son nom et son extension d'origine ; le viewer intégré de solivram sait afficher directement le contenu d'un fichier texte ou de code sans qu'aucun téléchargement ne soit nécessaire pour le consulter, ce qui rend la lecture immédiate pour un visiteur.

Aucune configuration technique n'est requise au-delà de cette organisation en dossiers : la publication proprement dite se joue ensuite sur un seul réglage, détaillé dans les sections suivantes — la visibilité du projet.

Extrait ou totalité : vous choisissez ce qui est exposé

Publier son code pour audit ne signifie pas tout montrer. Le propriétaire d'un projet Multi-Doc choisit lui-même, fichier par fichier et dossier par dossier, ce qu'il dépose — rien n'est extrait ou dupliqué automatiquement depuis une source externe.

Certains choisiront de déposer un extrait ciblé : un module isolé dont on veut un avis, un algorithme précis, une portion jugée sensible ou complexe. D'autres préféreront déposer la totalité d'un projet, pour une revue exhaustive. Les deux approches utilisent exactement le même mécanisme d'upload — seule la sélection de ce qu'on dépose change.

Ce choix reste réversible à tout moment : ajouter des fichiers plus tard, en retirer, ou renommer un dossier ne casse rien côté visiteurs — le contenu affiché reflète toujours l'état actuel du projet.

Visibilité publique : audité par tout le monde

Un projet Multi-Doc peut être réglé en visibilité Public. Dans cet état, n'importe quel visiteur — même sans compte, même non connecté — peut consulter les fichiers déposés, les parcourir dossier par dossier, et lire leur contenu directement dans le navigateur.

C'est le réglage le plus ouvert : il correspond à un audit par le plus grand nombre, sans aucune barrière d'accès. Un projet public est aussi éligible à l'indexation par le moteur de recherche interne de la plateforme et par les moteurs de recherche externes, ce qui augmente ses chances d'être effectivement consulté plutôt que de rester une adresse connue d'une seule personne.

Ce réglage convient à un code qu'on veut exposer largement : une bibliothèque partagée, un exemple pédagogique, ou simplement la volonté explicite de maximiser le nombre de regards portés dessus.

Visibilité membres : un cercle plus restreint

À l'inverse, la visibilité Membres restreint la consultation aux personnes qui possèdent un compte solivram et sont connectées — un visiteur anonyme se voit renvoyé vers la page de connexion, sans jamais accéder au contenu.

Ce réglage convient à un contexte plus mesuré : partager un code avec une communauté de pairs identifiés plutôt qu'avec l'intégralité d'Internet, faire relire un travail en cours à un cercle de confiance, ou simplement préférer ne pas indexer publiquement un projet tout en le gardant consultable par toute personne inscrite.

Le même projet peut d'ailleurs changer de visibilité à tout moment — commencer en Membres pour une première relecture restreinte, puis passer en Public une fois le code jugé prêt pour une audience plus large, ou l'inverse.

Partager le lien de son projet

Une fois le projet créé et sa visibilité choisie, chaque projet dispose d'une adresse directe et stable — un lien qu'on peut communiquer à qui l'on souhaite : par message, sur un autre site, ou en le publiant soi-même sur une page vitrine, exactement comme cette page le fait.

Envoyer ce lien reste le moyen le plus direct de faire auditer son code par une personne précise : un pair, un employeur potentiel, un contributeur qu'on invite à relire un module avant de l'intégrer. Aucune inscription n'est nécessaire pour consulter un projet Public ; une simple connexion suffit pour un projet en visibilité Membres.

Se faire découvrir : promotion et recherche interne

Au-delà du lien partagé directement, un projet Public peut aussi être découvert sans qu'on ait communiqué son adresse à personne. Le moteur de recherche interne de solivram indexe les projets publics — un visiteur qui cherche un mot-clé présent dans un titre, une description ou le contenu d'un fichier peut tomber directement dessus.

La plateforme propose également une fonction de promotion, qui met en avant un contenu sur sa page « Découvrir » publique — un moyen supplémentaire de donner de la visibilité à un projet qu'on souhaite voir audité par le plus de monde possible, sans dépendre uniquement du bouche-à-oreille.

Ces deux mécanismes sont optionnels et n'affectent jamais la visibilité déjà choisie pour le projet : un projet réglé en Membres n'apparaît ni dans la recherche anonyme, ni dans « Découvrir » pour un visiteur non connecté.

Explorer, forker, télécharger : ce que peut faire un relecteur

Une fois sur la page d'un projet, un relecteur dispose de plusieurs façons de l'examiner. Le viewer intégré affiche directement le contenu des fichiers texte et de code, sans téléchargement préalable — la lecture est immédiate, fichier après fichier.

Quand le propriétaire l'autorise, le projet peut aussi être forké : un relecteur obtient alors sa propre copie indépendante, qu'il peut faire évoluer de son côté sans jamais modifier l'original. Il peut également, si le propriétaire l'a autorisé, télécharger une archive complète du projet pour l'étudier hors ligne, avec ses propres outils.

Ces trois façons de consulter un projet — lire en ligne, forker, télécharger — sont chacune indépendamment activables par le propriétaire : lui seul décide, projet par projet, jusqu'où va l'ouverture qu'il propose.