CERTHIX / Déploiement cloud

Préparer le service quotidien et sa reprise.

Distinguez les responsabilités du navigateur, de l’API, de la base et du stockage.
Séparez les tests de la production et contrôlez les mises en service.
Définissez la reprise et les responsabilités avec la région d’hébergement.

Discuter de vos besoins ↗Voir des exemples concrets ↓

Déploiement cloud

Architecture et exploitation

Architecture applicative

Le serveur Next.js gère la session du navigateur ; l’API NestJS contrôle les autorisations et les règles des dossiers.
PostgreSQL conserve les données structurées. Azure Blob Storage reçoit les pièces jointes avec une autorisation de courte durée.
Les traitements de fond et les événements de stockage fiables suivent un circuit distinct de l’envoi du fichier.

Le chemin cloud implémenté

Le dépôt contient les définitions Azure de la démonstration hébergée : registre de conteneurs, environnement Container Apps, API et PostgreSQL Flexible Server.
Cet environnement ne constitue pas un engagement de disponibilité en production.
AWS et Google Cloud ne sont pas des déploiements établis dans le code examiné ; un autre fournisseur nécessite une étude technique et opérationnelle.

Environnements et versions

Développement, recette et production nécessitent des configurations, identifiants et données séparés. Les démonstrations utilisent des données fictives.
Les migrations de base sont versionnées avec l’application. Une livraison doit prévoir la compatibilité du schéma et la reprise après échec.
Testez ensemble l’identité, l’accès au stockage et les traitements de fond avant toute utilisation réelle.

Identité, secrets et réseau

En production, Entra ID établit l’identité ; Certhix applique ensuite ses propres autorisations.
L’intégration du stockage est conçue pour une identité managée Azure, sans clé de compte de stockage dans le navigateur.
Le réseau privé, la protection en périphérie, les secrets et les connexions autorisées relèvent de la configuration de production.

Sauvegardes et restauration

L’objectif de point de reprise fixe la quantité maximale de travail récent susceptible d’être perdue.
L’objectif de délai de reprise fixe le temps de retour du service ; ces objectifs dépendent de l’environnement et du contrat.
Testez la restauration des dossiers et des fichiers. La présence d’une sauvegarde ne démontre pas sa restaurabilité.

Responsabilités opérationnelles

Désignez les responsables des mises à jour, des droits, des alertes et de la réponse aux incidents.
Surveillez l’API, la connexion à la base et le traitement des preuves ; l’affichage de l’accueil ne suffit pas.
Documentez la maintenance, les procédures de restauration et les contacts d’escalade.

Exemples de processus

Dans le travail quotidien

Passer de la démonstration à la production

Créez l’environnement et configurez les identités et les droits.
Testez inspection, pièce jointe, révision et correction sur tout le circuit.
Validez la supervision et la restauration avant les données réelles.

Reprendre après une panne

Déterminez le point de reprise et restaurez les données et fichiers nécessaires.
Vérifiez les droits et les liens avant la réouverture.
Consignez le résultat et les opérations à ressaisir.