Les Clés de la maison : quand votre boîte mail devient votre identité

Sur l'identité, l'accès, et l'infrastructure qu'on possède déjà

Le problème du passe-partout

Il y a un moment, dans tout projet auto-hébergé, où l'on veut laisser entrer quelqu'un d'autre. Un collaborateur, un contributeur, quelqu'un qui a quelque chose à apporter. L'instinct est généreux — partager le dépôt, donner l'accès en écriture, et que le travail commence.

Avec GitHub, c'est trivial. On ajoute un collaborateur, il clone, il pousse. GitHub gère l'authentification, les autorisations, la protection des branches. On n'y pense pas, parce que quelqu'un d'autre a déjà résolu le problème.

Mais nous n'hébergeons pas notre code sur GitHub. Le dépôt vit sur notre VPS — la même machine qui fait tourner nos workflows, notre serveur mail, notre documentation, notre plateforme d'IA civique. Quand quelqu'un demande à contribuer, la réponse standard, c'est : un accès SSH.

Un accès SSH à un VPS, c'est un passe-partout. On peut le restreindre, le chrooter, le configurer jusqu'à le rendre à peine utilisable — mais au fond, on donne à quelqu'un un shell sur la machine où tout tourne. C'est comme prêter ses clés de maison parce que quelqu'un veut emprunter un livre sur l'étagère.

La contradiction

On veut deux choses qui semblent incompatibles :

Les collaborateurs doivent pouvoir pousser du code sur leurs propres branches.

Les collaborateurs ne doivent toucher à rien d'autre sur la machine.

C'est ce que TRIZ appelle une contradiction physique — la même ressource (l'accès VPS) doit être simultanément ouverte et fermée. L'approche SSH tente de résoudre ça par la restriction : donner l'accès, puis en retirer la plus grande partie. C'est se battre contre l'architecture.

La résolution TRIZ, c'est le Principe n°28 — Substitution mécanique : ne pas restreindre le mécanisme, le remplacer entièrement. Au lieu de SSH (qui est fondamentalement un accès shell), utiliser HTTP (qui est fondamentalement un accès protocolaire). Le collaborateur ne touche jamais la machine. Il parle le protocole git en HTTPS, et quelque chose au milieu décide de ce qu'il peut voir et faire.

La réponse tournait déjà

Voilà ce qui nous a surpris : le fournisseur d'identité dont on avait besoin tournait déjà. Depuis des mois.

Le serveur mail.

Chaque collaborateur possède déjà une adresse @lockilabs.com. Cette adresse, c'est son identité — c'est avec elle qu'il s'authentifie au webmail, qu'il reçoit les communications du projet, qu'il est connu au sein de l'équipe. Le serveur mail parle IMAP, et IMAP est un protocole d'authentification. On envoie des identifiants, le serveur répond oui ou non.

Alors au lieu de construire un système d'identité — pas de LDAP, pas de fournisseur OAuth, pas de service d'authentification externe — on pose au serveur mail une question à laquelle il sait déjà répondre : est-ce que cette personne est bien celle qu'elle prétend être ?

C'est le Principe TRIZ n°2 — Extraction. L'identité n'a pas sa place dans git. Elle n'a pas sa place dans un nouveau système. Elle est là où elle vit déjà. Il suffisait de poser la question.

Cinq couches, cinq responsabilités

L'architecture qui a émergé comporte cinq couches, et chacune fait exactement une chose :

Traefik termine le TLS et route git.lockilabs.com vers le proxy. Il fait déjà ça pour tous les autres services. Une règle de routage de plus.

Le proxy authentifie la requête auprès du serveur mail via IMAP. Si les identifiants sont bons, il sait qui vous êtes. Ensuite, il vérifie ce que vous avez le droit de voir — quelles branches, quelles refs. Il filtre la réponse pour que vous ne voyiez que ce qui vous appartient.

git-http-backend sert le dépôt par HTTP. Il ne sait rien des utilisateurs ni des permissions. Il est sans état, mécanique, fiable.

Le hook pre-receive est la dernière ligne de défense. Même si quelque chose contourne le proxy, le hook vérifie : cette personne a-t-elle le droit de pousser sur cette branche ? Si non, le push est rejeté avant d'atterrir. Défense en profondeur — la barrière peu coûteuse qui empêche le dégât coûteux.

Le fichier ACL est une simple correspondance en texte brut entre identités et branches. Versionné, révisable, auditable. Pas de base de données, pas de panneau d'administration. Un fichier qui dit qui peut toucher quoi.

Chaque couche peut tomber sans entraîner les autres. Chacune peut être testée indépendamment. Aucune couche ne résout le problème d'une autre.

Identité et communication

Une distinction est devenue claire en concevant tout ça : identité et communication ne sont pas la même chose.

[email protected], c'est l'identité. C'est le compte qui s'authentifie à git, au webmail, à tout service qui a besoin de savoir qui vous êtes. Ce n'est pas public. Ce n'est pas partagé. C'est la clé.

[email protected], c'est la communication. C'est l'adresse sur le site, celle à laquelle on écrit, celle qui redirige. Elle est publique par nature.

La plupart des systèmes confondent les deux. Votre email est votre identifiant est votre adresse de contact est votre nom d'affichage. Mais ils remplissent des fonctions différentes, et les fusionner signifie qu'on ne peut pas changer l'un sans affecter l'autre.

Séparation des responsabilités, appliquée à l'identité elle-même.

Une seule commande pour accueillir

Tout le système converge vers un seul script : add-collaborator.sh. Une commande qui crée le compte mail, crée la branche, met à jour l'ACL. Tout ce dont un nouveau collaborateur a besoin pour commencer à contribuer, sans que personne ne touche à la configuration SSH, aux conteneurs Docker ou aux entrailles du serveur.

C'est ça, la souveraineté en pratique — pas un mur, mais une porte avec un protocole clair. On sait qui est à l'intérieur. On sait ce qu'il peut atteindre. Et le mécanisme pour accorder l'accès est aussi simple que de lancer une commande.

Ce que la boîte mail savait

On a passé des mois à construire de l'infrastructure — Traefik pour le routage, docker-mailserver pour les communications, n8n pour l'orchestration. Chaque pièce a été construite pour son propre usage. Aucune n'avait été conçue pour résoudre le problème du contrôle d'accès.

Mais l'infrastructure ne sait pas à quoi elle sert tant qu'on ne lui pose pas la bonne question. Le serveur mail n'attendait pas de devenir un fournisseur d'identité. Il s'est simplement avéré qu'il en était déjà un — on s'authentifiait auprès de lui chaque fois qu'on relevait nos mails. La question n'était pas « que devons-nous construire ? » C'était « qu'avons-nous déjà construit sans l'avoir pleinement compris ? »

La meilleure architecture n'est pas celle qui a le plus de composants. C'est celle qui découvre des capacités dans ce qui existe déjà.

Voir aussi : Knowledge Unguarded Is Knowledge Stolen | What the Well Remembers | The Day the Lighthouse Dimmed