Le code de l’entreprise n’a rien à faire chez les autres
SSemRepo est un dépôt que votre entreprise exploite elle-même. Dépôts, tickets, revue de code et wiki arrivent d’un seul tenant, et les développeurs gardent les commandes git qu’ils connaissent déjà.
Un dépôt externe démarre vite. En échange, la conception de votre produit et la trace de qui a changé quoi, et quand, s’accumulent sur une infrastructure qui n’est pas la vôtre.
Votre bien le plus précieux est ailleurs
Le code source, c’est tout ce que l’entreprise a construit. L’effacer n’est pas un geste que vous faites mais une demande que vous adressez, et la durée des sauvegardes est fixée par des conditions d’utilisation.
Le lien tombe, le travail s’arrête
Sur un réseau interne fermé, en usine ou sur un site sans accès sortant, un simple clone ne passe pas. Certains endroits sont hors d’atteinte physiquement, pas seulement par règlement.
Face à un audit, rien à répondre
Quand la finance, la santé ou le secteur public demande où ce code est conservé, brandir les conditions d’un prestataire est la seule réponse disponible.
Produit
Un dépôt n’est qu’un début
Quand l’endroit qui héberge le code et celui où l’on en discute sont séparés, on finit par acheter un second outil. SSemRepo livre les trois ensemble.
01
Dépôts
git clone et push passent en HTTPS tels quels. Fichiers, commits et différences se lisent dans le navigateur, et les dépôts Subversion repris se lisent sur les mêmes écrans.
02
Collaboration
Tickets, jalons, étiquettes et assignations ; demandes de fusion et revue de code ; forum et wiki. Tout tient dans un seul projet.
03
Exploitation
Groupes et droits, validation des inscriptions, notifications et modèles de courriel, logo du site et sauvegardes se modifient depuis l’administration. Rien de tout cela n’exige un redéploiement.
Fonctions
Ce qu’une équipe touche chaque jour
Dépôts Git
Clone et push en HTTPS, branches et étiquettes, liste des commits et différences, lecture des fichiers, édition web, forks.
Subversion aussi
Les révisions, fichiers et différences d’un dépôt svn repris se lisent sur les mêmes écrans que git. Inutile de jeter l’ancien.
Tickets et jalons
Étiquettes, assignations et jalons, tickets parents et enfants, pièces jointes et commentaires, et une recherche qui ne rend que le visible.
Demandes de fusion
Différences entre branches, commentaires de revue fichier par fichier, signalement des conflits, fusion et fermeture automatique.
Forum et wiki
Les annonces au forum, les règles et la conception au wiki — avec le même éditeur et les mêmes pièces jointes que les tickets.
Dix langues
Le produit parle coréen, anglais, japonais, chinois, allemand, russe, français, vietnamien, indonésien et espagnol.
Écrans
Les choses familières à leur place habituelle
Le vrai coût d’un outil, c’est le temps passé à l’apprendre. La disposition suit ce que les développeurs connaissent déjà — les onglets du projet en haut, le travail au centre, le résumé à droite.
À propos de cet écran
Tickets — Filtrez par étiquette, assignation ou jalon. La liste ne montre que les tickets des projets que vous avez le droit de voir.
Revue de code — Parcourez les modifications d’une demande de fusion fichier par fichier et commentez les lignes modifiées — la discussion reste à côté du code.
Discussion — Descriptions et commentaires sont en Markdown : listes de tâches, blocs de code et tableaux s’affichent tels quels, et l’assignation, les étiquettes et le jalon sont regroupés à droite.
Jalons — L’avancement se calcule à partir des tickets fermés : l’échéance et ce qu’il reste à faire tiennent sur un seul écran.
Sécurité — La connexion peut aussi demander le code à six chiffres d’une application d’authentification. Une fois activée, git et l’API n’acceptent plus le mot de passe, seulement un jeton d’accès personnel.
Administration — Valider les inscriptions, verrouiller un compte, nommer un administrateur, envoyer un lien de réinitialisation du mot de passe, désactiver la double authentification : tout se fait depuis l’administration.
L’entreprise, les personnes et le code visibles sur ces écrans sont des exemples.
Ligne de commande
Ce qui se fait à l’écran se fait aussi en une commande
Ce qu’une personne enchaîne à la souris et ce qu’une machine répète ne sont pas le même travail. SSemRepo livre son propre outil en ligne de commande — à appeler depuis un script, à accrocher après une compilation, ou à confier à un agent de programmation.
ssemhub
$ ssemhub issue create ssem/payments-api --title "Le remboursement est porté deux fois au solde" --labels anomalie --assignee kim #128 Le remboursement est porté deux fois au solde Ouvert$ ssemhub pr list ssem/payments-api --state OPEN #41 Corriger le double remboursement sur le solde En revue
Presque tout ce qu’offrent les écrans
Tickets, forum, wiki, demandes de fusion, jalons, groupes, jusqu’à l’administration du site. Les résultats reviennent en tableau pour les humains ou en JSON pour les machines.
Plusieurs comptes sur une machine
Séparez les comptes en profils, puis liez un répertoire au compte qui doit y travailler. En dessous, c’est ce compte, sans rien demander.
L’authentification git aussi
Il se branche comme assistant d’identifiants git : le push cesse de réclamer un mot de passe. Les secrets enregistrés sont chiffrés pour cette machine ; copiés ailleurs, ils ne s’ouvrent pas.
Pensé pour les agents de code
Le mode d’emploi est fourni, prêt à être branché sur un outil d’IA. « Ouvre un ticket pour ce bogue » devient alors quelque chose qui s’exécute.
À propos de cette session
Un projet se désigne par <propriétaire>/<nom>. Mettez en valeurs par défaut ceux que vous utilisez souvent et omettez-les.
Créer quelque chose vous en renvoie le numéro. C’est par ce numéro qu’on commente, qu’on change l’état et qu’on assigne.
La lecture suit la même forme. Les conditions qui restreignent une liste sont celles des filtres de l’écran.
Architecture
Le déploiement d’un coup d’œil
Navigateurs et clients git arrivent à la même adresse. Le serveur web les passe à Tomcat ; l’historique va dans PostgreSQL et les fichiers des dépôts restent sur votre disque.
À propos de ce schéma
De gauche à droite : développeurs → serveur web → SSemRepo → stockage. Chaque flèche s’arrête à l’intérieur du périmètre de l’entreprise.
Les traits pleins sont les chemins des personnes. L’écran du navigateur et le clone ou push git entrent par le même port 443.
La branche du bas, ce sont les fichiers. Dépôts et pièces jointes reposent sur votre disque et non dans la base — une sauvegarde est une copie de fichiers.
Le trait pointillé est la notification. Elle ne sort que par votre SMTP, et lorsqu’elle échoue le produit ne prétend pas l’avoir envoyée.
Aucune flèche ne quitte le périmètre. Le produit fonctionne à l’identique sur un réseau sans accès sortant.
Migration
Vos dépôts actuels vous suivent
Les équipes qui ont déjà des années derrière elles sont plus nombreuses que celles qui démarrent. Les dépôts git et svn, les tickets et les pièces jointes de l’outil que vous utilisez aujourd’hui sont repris, avec la procédure et les outils qui vont avec.
La base de données
Tickets, commentaires et historique sont lus dans la base de votre outil actuel et déplacés vers PostgreSQL. Les valeurs sont lues par le pilote et écrites telles quelles, jamais réécrites comme du texte.
Dépôts et fichiers
Les dépôts git et svn ainsi que les fichiers téléversés sont copiés entiers, répertoire compris. Un dépôt reste un objet standard quel que soit l’outil d’origine : il n’y a rien à ajuster.
Comptes et droits
Utilisateurs, groupes et rôles suivent. Lorsque le schéma de mots de passe correspond, les anciens mots de passe fonctionnent encore et personne n’a à se réinscrire.
Les faire tourner côte à côte
Avant d’éteindre l’ancien système, les mêmes données se comparent sur les deux écrans. On avance en gardant un chemin de retour.
L’ampleur et le calendrier d’une migration se déduisent du nombre de dépôts et de la taille du disque. Écrivez-nous : nous regarderons votre environnement avec vous.
Mise en place
De l’installation au premier push, en quatre étapes
1
Lever le serveur
Deux conteneurs — l’application et PostgreSQL. La seule décision est le disque où vivront les dépôts.
2
Schéma et premier administrateur
Créer les tables, charger les données initiales, puis créer le compte administrateur. Les commandes sont écrites dans le guide.
3
Domaine et certificat
Pointer votre domaine et monter HTTPS. Comme le trafic git passe par là, il suffit de desserrer la limite de taille des requêtes.
4
Faire entrer l’équipe
Choisir le mode d’inscription, puis créer groupes et projets. En cas de migration, c’est ici que l’ancien matériel entre.
Technique
Construit pour rester réparable
Java 21 · Tomcat 11
Un serveur Java ordinaire suffit. Votre équipe d’exploitation le démarre et le redémarre comme elle le fait déjà.
PostgreSQL · JDBC brut
Le SQL s’écrit directement, sans couche de correspondance entre les deux. Une requête lente se trouve dans la requête.
Interface Svelte 5
Le premier écran a été allégé pour s’afficher vite, et même les polices sont servies depuis votre réseau.
Plus de 1 700 contrôles automatiques
Ils tournent contre un vrai serveur — créer un projet, y pousser, ouvrir une demande de fusion — et non contre des simulacres.
Vous étudiez SSemRepo ?
Dites-nous la taille de votre équipe et ce que vous utilisez aujourd’hui ; nous proposerons une configuration adaptée et vous aiderons pour l’essai et la migration.