Open source · Self-hosted · macOS et Windows
Le versioning de GitHub.
La simplicité d'Obsidian.
La gouvernance en plus.
Le contexte et les skills de ta boîte dans un dossier commun, avec un historique complet et des droits dossier par dossier : qui voit quoi, qui modifie quoi. Ces droits-là, ni GitHub ni Obsidian ne savent les donner. Git tourne côté serveur, personne n'a de commande à taper.
Tes skills existent déjà. Éparpillés.
Dans toutes les boîtes, des skills commencent à apparaître. Un associé a appris à son IA à rédiger ses comptes rendus. Une commerciale a construit son contexte de prospection. Un chef de projet a trois procédures qui tournent.
Tout ça vit sur la licence de chacun, dans son coin. Rien de commun, rien de structuré, et rien qui suit le jour où vous changez d'outil.
Il y a un sujet de méthode. Il y a aussi un sujet d'outil, et c'est celui-là qui bloque : il n'existe pas d'endroit fait pour ça. Même dans une boîte tech.
Trois libertés
On a gardé ce que GitHub fait bien, retiré ce qui le rend inaccessible, ajouté ce qui lui manque.
- 01 Gouverné
Des droits dossier par dossier : qui voit quoi, qui modifie quoi. Ce dossier client à deux personnes, ce skill de facturation à la compta, le contexte commercial à toute l'équipe.
- 02 Portable
Un dossier neutre, lu par Claude Code, Cursor et Codex sans copie ni conversion. Tu changes d'outil, ton contexte suit.
- 03 À toi
Self-hosted et open source (AGPL). Le texte reste sur ton serveur. Tu peux lire chaque ligne de code.
En pratique
Un serveur, une page web, un dossier sur chaque Mac.
- Le serveur, chez toi. Tu le fais tourner sur ta machine ou sur ton hébergeur. Les fichiers et l'historique complet y restent, et c'est la seule chose à sauvegarder.
- Les droits, dans une page web. Tu décides qui accède à quel dossier, en lecture ou en écriture, et tu le changes quand tu veux. Les skills se partagent au même titre que les documents, avec les mêmes droits.
- Les dossiers, sur les postes. Chacun installe l'application, choisit où poser ses dossiers, et ils se synchronisent tout seuls. Ce sont des fichiers texte ordinaires : Claude Code, Cursor et Codex les lisent là où ils sont, sans import ni conversion.
Ce que tu utilises aujourd'hui
Pourquoi rien d'autre ne coche toutes les cases.
| Critère | Plans entreprise | Obsidian | GitHub | Vécu |
|---|---|---|---|---|
| Dossier de contexte commun | ± partiel | ✓ oui | ✓ oui | ✓ oui |
| Droits par dossier (qui voit / édite quoi) | ± partiel | ✗ non | ✗ non | ✓ oui |
| Partage des skills, pas que les docs | ✓ oui | ✗ non | ✓ oui | ✓ oui |
| Lu par plusieurs outils IA | ✗ non | ✗ non | ± partiel | ✓ oui |
| Sans commit ni merge à penser | ✓ oui | ✓ oui | ✗ non | ✓ oui |
| Chez toi, open source | ✗ non | ± partiel | ± partiel | ✓ oui |
✓ oui · ± partiel · ✗ non
GitLab, Gitea et Forgejo se lisent sur la colonne GitHub, avec un avantage réel sur la dernière ligne : eux s'hébergent chez toi et sont open source. Ils butent sur les deux mêmes lignes que lui, les droits par dossier et le vocabulaire git. C'est l'objet de la section suivante.
L'objection
« Un GitLab auto-hébergé fait déjà ça. »
C'est la première réaction de ceux qui connaissent ces outils, et elle est saine. GitLab, Gitea et Forgejo hébergent des fichiers versionnés, tournent chez toi et sont open source. Trois choses les séparent de ce que fait Vécu.
- Les droits s'arrêtent au dépôt. Ouvrir un seul dossier à une seule personne oblige à en faire un dépôt séparé. Puis un autre. Le fichier CODEOWNERS, cité souvent comme la réponse, déclenche des demandes de relecture, exige le droit d'écriture sur le dépôt entier, et ne restreint la lecture de rien.
- Le travail commence après le dépôt. Chaque fichier doit atterrir sur la machine de chacun, dans le dossier que son IA lit déjà, et repartir modifié sans écraser celui d'à côté. Un dépôt héberge et attend qu'on vienne le chercher. Vécu fait ce trajet, en continu, sur les postes.
- Le prix d'entrée est un vocabulaire. Cloner, brancher, commiter, résoudre un conflit. Une équipe dont la moitié n'écrit pas de code ne tient pas trois semaines. Chez Vécu, git tourne côté serveur et l'historique se lit dans une page web.
L'inverse est vrai aussi, et il vaut mieux le dire. Si ton équipe est à l'aise avec git et que tout le monde a besoin de tout voir, un GitLab auto-hébergé fait le travail, et il le fera mieux que nous sur du code. Vécu devient utile le jour où une partie de l'équipe n'est pas développeuse, ou le jour où tout le monde ne doit pas tout voir.
Quelques points à avoir en tête
- Pas un drive. Le périmètre, c'est le texte. Images, PDF et binaires restent dehors, volontairement.
- Vécu distribue, il n'exécute rien. Aucun runtime, aucun secret, aucun agent qui tourne.
- macOS et Windows, pas Linux. L'application Windows n'est pas encore signée : le système affiche un avertissement à la première ouverture.
On l'utilise nous-mêmes, tous les jours
Notre propre second cerveau d'entreprise tourne dessus. On a désinstallé l'outil de synchronisation qu'on utilisait avant, et on n'y est jamais revenus.
C'est open source. Tu n'as pas à nous croire : le code est lisible, ligne par ligne.
Pour qui
Les équipes qui travaillent déjà avec des agents et qui veulent une base commune qu'elles maîtrisent. Dirigeants et C-level techniques, CTO, COO.
Si l'IA est encore un gadget chez toi, ce n'est pas encore le moment, et c'est ok.
Le code est ouvert.
Clone le repo, héberge ton serveur, invite ton équipe. Ou parle-nous si tu veux qu'on le déploie chez toi.