uHub
Un portail de travail, installé chez vous. Vos outils de tous les jours derrière une seule porte d'entrée et une seule identité.
>le produit
Une seule porte, une seule identité, et vous activez ce dont vous vous servez.
Une organisation de dix personnes utilise couramment dix services séparés, chacun avec son adresse, son mot de passe, sa facture et sa propre idée de qui a le droit de quoi. uHub les réunit sans les remplacer : un portail unique devant des briques qui restent des briques.
Chaque outil garde son moteur d'origine. uHub tient l'entrée, les droits, le journal et la vue d'ensemble, et parle à chaque brique par son interface publique. Le reste attend, prêt, tant que vous n'en avez pas l'usage.
Branchée sur un système en désordre, elle restitue du désordre. C'est pour cela qu'elle n'est pas un module de plus : elle se pose sur le pôle organisation, sur une matière déjà classée, inventoriée et datée. Elle cherche, elle recoupe, elle prépare l'arbitrage.
Le modèle reste votre choix, le calcul reste sur vos machines, et vos documents n'entraînent personne. Le travail porte sur le branchement, qui doit rester trivial.
?ce que ça règle
Un jour, quelqu'un vous demande de prouver.
Un client, un mois avant de renouveler. Un assureur. Un auditeur. Un appel d'offres. La question arrive toujours dans les mêmes termes : comment protégez-vous nos données ? Votre installation tient. Il vous reste à le montrer.
C'est à cette demande que uHub répond, et il y répond par trois mécanismes plutôt que par un dossier.
La commande qui vérifie est celle qui déploie
L'installation est décrite dans des fichiers texte versionnés. Les rejouer deux fois ne fait pas l'installation deux fois : c'est l'idempotence. Les rejouer sur une machine qui a dérivé la ramène à l'état décrit : c'est la convergence. Un contrôle à blanc affiche l'écart entre ce qui est écrit et ce qui tourne, à tout moment, sans rien interrompre.
Le journal des actions refuse d'être modifié
Qui a fait quoi, quand, depuis quelle adresse. La base de données refuse la modification et la suppression sur cette table. La durée de conservation se règle, jusqu'à dix ans.
La restauration se teste avec un humain
Un script qui se termine sans erreur prouve que le script tourne, pas que la sauvegarde est utilisable. Cette vérification se fait à la main, et elle est datée. C'est la seule façon d'écrire une date de dernière restauration réussie et de la tenir devant un tiers.
La preuve n'est pas un dossier.
C'est le déploiement.
#les situations
Quatre situations, la même chaîne d'installation.
Le produit ne change pas, l'infrastructure qui le porte, si. Reconnaissez la vôtre : voici ce qu'il faut prévoir dans chaque cas.
- Une seule machine, la vôtre
- Sauvegarde sur disque externe, ou sur un stockage objet européen
- Aucun serveur à tenir, aucune astreinte
- Un noeud de calcul, six coeurs, trente-deux gigaoctets à code correcteur, disque à état solide
- Un noeud de stockage, tenu hors du cluster
- Un noeud local pour le développement, le test et la reprise
- Liaison chiffrée entre les sites
- Trois machines physiques, une par plan de contrôle
- Dix-huit processeurs virtuels, trente gigaoctets, trois cents gigaoctets répartis sur six noeuds
- Stockage objet répliqué, sauvegarde hors site
- Chiffrement au repos, déverrouillage par le réseau au démarrage
- Plan de contrôle Kubernetes managé, chez l'opérateur de votre choix
- Deux noeuds de travail, à partir de quatre processeurs virtuels et seize gigaoctets
- Stockage bloc pour les bases, stockage objet en classe froide pour les sauvegardes
- Localisation européenne
=les spécifications
Spécifications techniques.
Ce que le produit demande, ce qu'il embarque, et ce sur quoi il s'appuie. Relevé dans le code et dans le chart de déploiement, pas dans une plaquette.
Le code vit sur codeberg.org/uyoop. Un espace de démonstration publique est en préparation.
Prestations et tarifs