Set‑OPS est un moteur Ansible qui construit et exploite tout un écosystème interne — identité, confiance, DNS, données, courriel, observabilité, forge, collaboration, web, et les applications de vos clients — sur votre propre grappe Proxmox. À partir d'un plan déclaratif. Puis il vous relie à un site partenaire qui garde la copie de vos sauvegardes et, si vous la demandez, une relève allumée. Sans SaaS. Sans conteneur. Et exploitable sans aucune IA.
édite le plan→
make instancier→
make deployer→
make prouver
Set‑OPS se pilote par un plan, pas par l'édition de l'inventaire. Les registres sont la source unique de vérité ; l'inventaire Ansible en est dérivé. Vous ne touchez jamais hosts.yml à la main.
Serveurs, applications, bases, domaines, nomenclature — des registres lisibles par la machine, votre seule source de vérité.
VMID, IP, VLAN et passerelle se dérivent d'un seul nombre, l'index que le site attribue. make instancier montre le diff avant d'appliquer.
Chaque groupe a son playbook homonyme. L'orchestrateur déploie socle → PKI → services → apps → agents, dans l'ordre.
make prouver rejoue les vérifications et produit un rapport horodaté. Le dépôt n'affirme jamais plus qu'il ne prouve.
Tout ce qu'un hébergeur met en ligne, Set‑OPS le tient en interne — en logiciel libre, sur systemd et paquets, sans dépendance à un géant. Voici, pilier par pilier, ce que vous déployez et exploitez. Le badge Éprouvé marque ce qui tourne sur des VM réelles ; Feuille de route ce qui est planifié.
Une identité, un mot de passe, pour tout le parc.
Votre propre autorité de certification. Tout le trafic interne, chiffré et vérifié.
verify-full, LDAPS, métriques & logs en HTTPS, LMTP vérifié.Un DNS interne cohérent, des noms publics signés, et un réseau convergé multi-tenant.
/etc/hosts, sans casser Internet.Bases relationnelles et cache, provisionnés depuis le registre.
Recevoir et envoyer, de bout en bout, sur votre infra.
:587 authentifiée (SASL déléguée à Dovecot).Déclare une exposition — tout le reste se dérive.
expose produit vhost + SAN de cert + enregistrement DNS + alias plancher, auto-dérivés.Voir toute la flotte : métriques, journaux, tableaux de bord, impact.
Vos services internes, adossés à l'identité commune.
Fichiers, agendas et documents partagés — sous la même identité.
Un client pousse son code dans sa forge ; Set‑OPS le déploie à la version qu'il nomme, en natif.
Sous les piliers, un socle commun tient l'ensemble : durcissement, pare-feu, sauvegardes, et l'outillage qui rend le tout reproductible.
Chaque VM naît sécurisée.
AuthenticationMethods publickey).Moindre privilège, dérivé du registre des flux.
ip saddr = moindre privilège, reste refusé.L'état, pas les VM — car l'infra se reconstruit par le code.
Une source unique, éditable en ligne de commande ou à l'écran.
make inventaire-ui.Tout passe par make et un plan. Un modèle générique socle — DNS, AC/PKI, edge TLS, courriel — est prêt à instancier, renseigner, déployer. Puis vous vivez dans le plan.
# 1 · créer un écosystème depuis le modèle public, générer l'inventaire $ make instance-creer NOM=OPS-MonOrg MODELE=socle $ ln -s ../OPS-MonOrg instance && make instancier-appliquer FORCE=1 Inventaire généré depuis le plan. # 2 · construire le gabarit, créer les VM, déployer la flotte $ make preparer-modele # socle + durcissement + cloud-init $ make reconstruire CONFIRMER=true # crée les VM PUIS déploie tout 13 hôtes déployés · 0 échec # 3 · valider et PROUVER $ make valider # recette sur la flotte vivante cibles UP · vhosts HTTPS · courriel livré · dépôts restaurés · 0 échec $ make prouver CONFORME : 102 OK, 0 échec, 0 sauté → docs/audit/preuve-AAAA-MM-JJ.md
Une VM Debian 13 minimale devient le golden template : socle, durcissement, cloud-init, qemu-guest-agent.
Clone via l'API Proxmox ; cloud-init donne hostname, clé, IP, DNS. VMID/IP/VLAN lus dans le plan.
Les playbooks de groupes appliquent l'état voulu, relançables sans effet de bord. La flotte converge.
Tout supprimer, puis make reconstruire : l'écosystème renaît du code, et son état revient de la sauvegarde.
Un écosystème peut en héberger d'autres. Le site porte le terrain — le réseau, les hyperviseurs, le dépôt de sauvegarde, la source des paquets. Chaque locataire y dérive son propre adressage, ses propres zones et ses propres machines. Et la frontière entre les deux n'est pas une politique : c'est une clé qui n'existe pas d'un côté.
La ligne exacte entre héberger et exploiter.
Le site fournit tout ce qu'il faut pour venir au monde.
Poser la première machine de quelqu'un d'autre.
L'infrastructure est reconstructible ; c'est l'état qu'on sauvegarde.
Deux sites qui ne se connaissent pas n'ont en commun que Set‑OPS. Ils deviennent partenaires par une fiche publique, vérifiée de vive voix par son empreinte, et aucun ne lit jamais le dépôt de l'autre. Le partenariat porte le socle commun. La relève, chaque locataire la demande s'il la veut.
Une entrée au plan du site, d'où tout le reste dérive.
Une flotte complète qui tourne déjà chez le partenaire.
Le plan d'un locataire ne nomme ni son site, ni ses adresses.
La mesure instruit ; la bascule reste un geste humain.
Un outil d'exploitation réelle, pas une démonstration. Chaque affirmation publique est tracée vers une commande de preuve rejouable — ou corrigée.
make verifier enchaîne lint, tests, cohérence, syntaxe et les preuves. Un dépôt qui se tient droit.
make prouver produit un rapport horodaté et rejouable — 102 preuves reliées au registre des affirmations. Une pièce justificative.
make valider : recette fonctionnelle sur la flotte vivante — cibles UP, vhosts HTTPS, courriel livré, sauvegardes restaurées.
make et le GUI suffisentFidèle au principe : on ne présente jamais comme prêt ce qui ne l'est pas. Deux cases de la version précédente en sont sorties : la relève par la copie croisée a été exercée, et un locataire a quitté son hébergeur pour son propre site, en emportant tout. Voici ce qui reste devant.
Les relèves tournent, et le déménagement s'est fait sans écart. Reste à faire désigner les serveurs de noms des deux sites par les registraires : un geste du responsable de chaque locataire, préparé nom par nom. D'ici là, une relève reste un exercice.
Le partenariat s'écrit en deux textes : la convention entre les deux sites, et la demande de relève de chaque locataire. Les deux sont rédigés et attendent leurs signatures.
Python et sites statiques aujourd'hui. Node et les binaires s'ajouteront au premier besoin d'un client, sur le même socle commun : utilisateur, systemd, nginx local, sonde, sauvegarde.
Trois niveaux accumulatifs pour attester la qualité d'un écosystème — garde-fou social inclus. La méthode d'attestation reste à trancher.
Un plan, votre grappe Proxmox, et tout un écosystème numérique — libre, chiffré, prouvé. Sous le ciel de l'Alliance Boréale.