Résolution des incidents #

La documentation ne charge pas #

Le Markdown utilise fetch. Servez le dossier : python3 -m http.server 8000.

Comprendre les pages d’erreur du site #

Code	Signification	Première vérification
400	requête incorrecte	URL, paramètres et taille de la requête
401	authentification requise	session, expiration du jeton et MFA
403	accès refusé	rôle, tenant et règle serveur
404	ressource introuvable	URL, route publiée et lien interne
429	limite de requêtes atteinte	temporisation, automatisation et adresse source
500	erreur interne	journaux, corrélation et dépendances
503	service indisponible	santé, maintenance, base, cache et workers

Les fichiers statiques à la racine fournissent un message sûr sans afficher de trace technique. Apache doit conserver le code HTTP d’origine via ErrorDocument; un navigateur qui affiche la page 404 avec un statut 200 produit une « soft 404 » défavorable au diagnostic et au référencement.

curl -I https://riskpilot.site/route-inexistante
curl -I https://riskpilot.site/503.html

La première commande doit renvoyer 404. La seconde permet uniquement d’inspecter les en-têtes de la page statique et ne simule pas une vraie panne 503.

Un conteneur est malsain #

docker compose ps
docker compose logs --tail=200 backend worker scheduler nginx
curl http://localhost:8080/api/health

Vérifiez PostgreSQL et Redis avant le backend, puis le backend avant Nginx.

Migration, emails ou données #

Contrôlez .env, puis make migrate. Pour les emails, vérifiez le fournisseur, le test d’envoi, le worker et Mailpit en local. Sauvegardez ensemble base, Redis, documents et clés JWT. N’utilisez jamais make reset pour dépanner une production : cette cible supprime les volumes.

Diagnostic structuré #

Commencez par docker compose ps, puis /api/health. Identifiez la couche : navigateur/Nginx, frontend, backend, PostgreSQL, Redis, worker ou fournisseur externe. Notez heure, utilisateur, tenant et corrélation avant de modifier l’état.

Connexion et MFA #

Vérifiez activité du compte, verrouillage, heure de l’appareil TOTP et sessions. Après réinitialisation, reconnectez tous les appareils. Ne désactivez pas globalement les contrôles pour résoudre un seul compte.

Documents #

Un téléchargement refusé peut venir du tenant, de l’ACL, du statut ou d’un partage expiré. Un upload rejeté peut dépasser 10 Mo, présenter un MIME incohérent ou échouer à l’antivirus. Contrôlez l’espace du volume.

Performance #

Examinez requêtes lentes, saturation PostgreSQL, mémoire PHP, file Redis et taille des exports. Corrigez la cause avant d’augmenter arbitrairement les limites.

Escalade #

Préservez logs et sauvegardes, décrivez reproduction et impact, puis joignez versions et commandes exécutées sans secret. Après résolution, documentez cause et prévention.

Diagnostic production rapide #

Si le service répond mais que les emails ou notifications restent en attente, vérifiez le healthcheck du worker et la profondeur de la file Messenger, pas seulement Redis. Si un déploiement échoue, relancez le contrôle d’environnement, les migrations et /api/health avant toute correction de données. Si un PDF manque de détails, régénérez un nouvel instantané après correction des registres sources ; ne modifiez jamais un instantané annuel immuable.