Limites et améliorations

Les limites ci-dessous sont connues et assumées pour le périmètre du projet. Chacune a une piste d'amélioration plus bas.

Limites connues

Disponibilité et données

• Un seul nœud de production : si tm-prod tombe, l'application est indisponible jusqu'à son redémarrage. Pas de haute disponibilité.
• Pas de sauvegarde : le volume de la base est uniquement sur le disque de tm-prod. Supprimer la VM, une panne de disque, docker compose down -v ou une migration destructrice ferait perdre les données.

Sécurité

• Jenkins est exposé sur internet, protégé seulement par sa page de connexion.
• L'utilisateur deploy est dans le groupe docker, ce qui équivaut à root : un Jenkins compromis pourrait prendre la main sur tm-prod.
• Jenkins tourne en root avec le socket Docker sur tm-tooling : c'est la raison pour laquelle il est isolé sur sa propre machine.
• Le jeton GitHub est un jeton classique avec le droit repo : il donne accès à tous les dépôts privés de son propriétaire, pas seulement à celui-ci.
• SSH est ouvert à tous sur les deux VM. Seule l'authentification par clé est acceptée, mais il n'y a pas de fail2ban.
• Jenkins fait confiance à la clé SSH de tm-prod à la première connexion (StrictHostKeyChecking=accept-new).
• Deux options anciennes dans casc.yml assouplissent la sécurité des scripts Job DSL et la vérification des clés Git.

Livraison

• Jusqu'à deux minutes de délai entre un merge et le début d'un build, à cause du polling. L'extension pathRestriction est dépréciée pour les jobs de type pipeline.
• Les retours arrière sont manuels : il faut remettre une ancienne image sous l'étiquette latest.
• Le frontend n'a pas de tests : seule la compilation est vérifiée.
• Trivy ne scanne que les paquets système : les dépendances Elixir et npm à l'intérieur des images ne sont pas auditées. mix deps.get signale actuellement des failles dans mint.
• Les tests backend sont lents la première fois (environ quatre minutes), car les dépendances sont compilées de zéro.
• L'application mobile n'a pas de pipeline : elle n'est ni vérifiée ni construite automatiquement.

Observabilité

• Pas de monitoring ni d'alerte : une panne n'est remarquée que par les utilisateurs.

API sur un autre domaine

• Le site web et l'API sont sur deux domaines différents : il faut une configuration CORS (CORS_ORIGINS) et une adresse d'API figée dans le frontend au moment du build.

Autres points relevés

Point	Détail
Une courte coupure à chaque déploiement	docker compose up -d back arrête l'ancien conteneur avant que le nouveau soit prêt : quelques secondes d'erreur 502
Des téléchargements sans version fixe	Le binaire docker-compose (latest), l'image jenkins/jenkins:lts et les plugins Jenkins changent à chaque reconstruction
Le registre sur un compte personnel	Les images sont publiées sous ghcr.io/saliehsab/. Si ce compte perd ses droits, plus rien ne se publie
Pas de limite de mémoire sur les conteneurs	Une fuite dans un service peut faire tomber les autres
Une variable inutilisée	TEST_TO est passée au conteneur back mais aucun code de l'API ne la lit

Améliorations possibles

Fiabilité

• Des instantanés quotidiens du disque de tm-prod, ou des exports pg_dump chaque nuit vers un bucket Cloud Storage avec une durée de conservation, plus une procédure de restauration documentée.
• Une base managée (Cloud SQL) pour les sauvegardes automatiques et la bascule en cas de panne.
• Un environnement de recette qui réutilise les mêmes rôles avec un autre inventaire.

Sécurité

• Mettre Jenkins derrière une couche d'authentification supplémentaire (basic auth ou forward auth Traefik), une liste d'IP autorisées, ou un VPN.
• Restreindre la clé de déploiement avec une commande forcée (command="..." dans authorized_keys) pour que Jenkins ne puisse lancer qu'un script de déploiement fixe, et retirer deploy du groupe docker.
• Remplacer le jeton classique par un jeton à droits fins limité à ce dépôt, si l'organisation le permet.
• Signer les images avec cosign et vérifier la signature avant de déployer.
• Fixer la clé SSH de tm-prod dans Jenkins au lieu de lui faire confiance à la première connexion.
• Restreindre SSH à des IP connues ou à Identity-Aware Proxy, et ajouter fail2ban.
• Retirer la section security ancienne de casc.yml.

Livraison

• Des audits de dépendances dans les pipelines : mix deps.audit et sobelow pour l'API, npm audit pour le site web.
• Des tests frontend (Vitest) et des tests de bout en bout après le déploiement.
• Des tests rapides après chaque déploiement, avec retour arrière automatique en cas d'échec.
• Des webhooks au lieu du polling, si les droits d'administration deviennent disponibles.
• Dependabot ou Renovate pour garder les dépendances et les images de base à jour.
• Un pipeline mobile (vérification des types, lint, puis EAS Build d'Expo pour les fichiers iOS et Android).
• Des versions fixes pour Jenkins, ses plugins et Docker Compose.

Observabilité

• Prometheus, Loki et Grafana sur tm-tooling, avec node-exporter et cAdvisor sur tm-prod, et des alertes sur la disponibilité, le disque et le taux d'erreurs.
• Sentry pour les erreurs de l'application.

Architecture

• Servir l'API sous time.jostud.com/api avec une règle de chemin Traefik : plus de CORS, plus d'adresse d'API figée au build.
• Terraform pour décrire les ressources Google Cloud en code.
• Kubernetes (k3s) avec Argo CD pour l'auto-réparation, les mises à jour progressives et les déploiements GitOps.