1. Vous recevez un zip
À chaque jalon, l'application complète, prête à pousser.
Comment nous livrons
La mise en production n'est pas un événement
Un zip standard, un manifeste, un contrôle de santé. Votre DSI peut lire notre contrat de déploiement avant de signer, et vérifier chaque point sur le dépôt que nous vous remettons.
Une release, en quatre temps
Vous n'avez rien à faire : ni SSH, ni commande, ni fenêtre de maintenance le soir.
2. La plateforme valide
Structure, variables d'environnement, migrations, contrôle de santé : un manquement bloque la livraison avant qu'elle n'atteigne le site en ligne.
3. Le serveur se met à jour
Dépendances, schéma, migrations, fichiers statiques, redémarrage, puis vérification des routes de santé.
4. Retour arrière possible
Si une vérification échoue, la version précédente saine reste déployable en un clic.
Ce que nous respectons, ligne par ligne
Chacune de ces règles est vérifiable sur le dépôt que nous vous remettons — pas une intention, un contrôle automatique.
01
Un zip standard, pas un dossier de déploiement
Nous livrons l'application : manage.py à la racine, requirements.txt, le manifeste, l'exemple d'environnement. Aucun script serveur, aucune configuration nginx maison, rien qui puisse diverger de ce que la plateforme génère.
02
La base de données vient de l'environnement
Aucune URL de base en dur, aucun repli SQLite. Sans la variable, l'application refuse de démarrer plutôt que de servir silencieusement une base vide — c'est la première cause de déploiement mort, et elle est éliminée par construction.
03
Un contrôle de santé qui ne touche pas la base
/healthz répond 200 dès que le processus vit, avant même la première migration. Les vérifications de dépendances vivent sur une route séparée et authentifiée.
04
Tout ce que le code lit est déclaré
Chaque variable d'environnement figure dans le manifeste et dans l'exemple, y compris celles qui ont une valeur par défaut. Votre exploitant sait exactement quoi poser sur le serveur, et rien de mort ne traîne dans la liste.
05
Les migrations sont commitées et vérifiées
Aucun changement de modèle en attente au moment de livrer. Une migration qui réécrit des données existantes est signalée pour que votre exploitant l'approuve, sauvegarde faite.
06
Les ports ne sont jamais écrits en dur
La plateforme alloue et route les ports ; nos commandes de service n'en mentionnent aucun. Un numéro écrit dans un manifeste ne fait qu'induire en erreur la personne suivante.
Ce que demandent les DSI
01 72 78 27 78Oui. La chaîne est standard : un projet Django, gunicorn, PostgreSQL, nginx. Rien dans le code ne dépend de notre plateforme, et le dépôt vous appartient.
Votre exploitant, et nous si vous nous confiez l'exploitation. Personne n'a besoin de se connecter en SSH pour livrer : tout passe par la chaîne, ce qui laisse une trace de chaque mise en ligne.
Il est refusé avant d'atteindre le site, avec le motif exact. Le site en ligne n'est pas touché : c'est la différence entre une livraison bloquée et un site tombé.
Quelques minutes pour une release ordinaire. La première mise en ligne prend une demi-journée, le temps de provisionner le serveur, la base et le certificat.
RGPD
EuropeDUCT
vérifiéCode
à vous
EuropeDUCT
vérifiéCode
à vous
Idée neuve ou application existante,construisons la bonne version.
CTO ou développeur ? Lire la documentation DUCT avant l'appel.