Comment utiliser l'IA quand on est distributed systems architect ?
Prompts et workflows 2026

En tant que distributed systems architect, tu dois realiser une analyse complete des performances et de la latence pour un systeme distribue. Tu reponds UNIQUEMENT en JSON valide.

Contexte: [NOMBRE_SERVICES] services communicates en mode [SYNCHRONE/ASYNSYNCHRONE], sur [ON-PREMISE/CLOUD/MIXTE], avec [NOMBRE_REQUETES_PAR_SECONDE] requetes/sec et [NOMBRE_UTILISATEURS] utilisateurs simultanes.

Analyse les points suivants et retourne un JSON avec 5 sections:
1. Latence end-to-end estimee avec breakdown par composant (network, compute, storage, queue)
2. Les 3 points de contention les plus probables avec cause racine et impact en ms
3. Strategie de mitagation pour chaque bottleneck (circuit-breaker, caching, batching, sharding)
4. Indicateurs de monitoring a mettre en place (SLO, SLA, Error Budget)
5. Recommandations de capacity planning avec [NOMBRE_NOEUDS] noeuds actuels et croissance [CROISSANCE_POURCENT]%

Chaque recommandation doit inclure un niveau de priorite (P1/P2/P3) et un effort d'implementation (LOW/MEDIUM/HIGH). Reponds uniquement avec le JSON structure, sans texte additionnel.

En tant que distributed systems architect, tu dois concevoir un schema complet de communication inter-services pour un systeme distribue. Tu reponds UNIQUEMENT en JSON valide.

Contexte: [NOMBRE_SERVICES] services a interconnecter dans un domaine [DOMAINE_METIER]. Contraintes: latence max [LATENCE_MS]ms, tolerance a la faute de [TYPE_FAUTE] (network partition, node crash, service degradation). equipe de [TAILLE_EQUIPE] developpeurs.

Pour chacun des [NOMBRE_SERVICES] services, definit:
1. Protocole de communication (REST/gRPC/Message Queue/Event-Driven) avec justification du choix
2. Pattern de resilience a implanter (Retry/Backoff/Circuit-Breaker/Bulkhead/Timeout) avec parametres recommandes
3. Schema de contrats entre services (synchrone via API gateway ou asynchrone via event bus)
4. Points de singulierite (single point of failure) et how to mitigate
5. Ordre de migration si le systeme actuel utilise [PROTOCOLE_ACTUEL]

Chaque service doit avoir une recommandations de stack technique (ex: Kafka pour event-driven, Envoy pour service mesh) avec version minimum recommandee et caveats known.

Tu es distributed systems architect, specialise en runbook operationnel pour systemes distribues en production. Tu generes un runbook complet en format Markdown structure.

Systeme cible: [NOM_SYSTEME] avec [NOMBRE_SERVICES] services deployes en [ENVIRONNEMENT], utilisant [STACK_TECHNIQUE], traitant [VOLUME_JOURNALIER] de donnees par jour.

Le runbook doit contenir exactement ces sections:
1. Architecture Overview: schema en texte ASCII avec les composants principaux et flux de donnees
2. Checklist pre-deployment: 10 checkpoints a valider avant chaque mise en production
3. Procedures d incident common: categorise par severite (SEV1/SEV2/SEV3) avec timeline de resolution et escalation path
4. Runbooks par service: pour [SERVICE_CRITIQUE_1] et [SERVICE_CRITIQUE_2], procedure de restart, health check, et backup restore
5. Monitoring et Alerting: liste de [NOMBRE_ALERTES] alertes critiques avec seuil, action auto, et contact humain a notifier
6. Post-mortem template: structure pour documenter chaque incident avec 5 sections (timeline, impact, cause racine, action immediate, prevention)

Chaque procedure doit etre suffisamment detaillee pour etre executee par un operateur sans knowledge prealable du systeme. Inclus les commandes shell concrete pour [OS_TYPE].

Tu es distributed systems architect avec expertise en SRE. Tu dois generer un rapport post-mortem complet pour un incident distribue. Tu reponds UNIQUEMENT en JSON valide.

Incident details:
- Service affecte: [SERVICE_AFFECTE]
- Duree totale: [DUREE_INCIDENT] minutes
- Impact: [IMPACT_METIER] (perte de transaction, degradation performance, data loss, etc.)
- Symptomes observes: [LISTE_SYMPTOMES]
- Signaux precursors: [SIGNAL_PRECURSOR] identifie en retro-spective
- equipe impliquee: [LISTE_EQUIPES]
- Detection: [ORIGINE_DETECTION] (monitoring, client, automate)

Genere le rapport en JSON avec ces 7 sections:
1. Executive Summary: paragraphe de 3 phrases decrivant l'incident, son impact et le statut final
2. Timeline detaillee: liste chronologique avec timestamp UTC, evenement, et auteur de l'action
3. Impact quantifie: nombre de [METRIC_IMPACT] affectee, duree de degradation, nombre de utilisateurs touches
4. Cause racine: identifie la cause premiere (pas le symptome) avec type (hardware, software, human, process)
5. Action immediate: liste des actions correctives avec temps de mitigation et mesuree
6. Action preventive: 5 recommandations ordonnees par priorite avec effort (1-week, 1-month, 3-month) et owner suggeste
7. Lessons learned: 3 apprentissages cles pour l'equipe avec tags [TAG_APPRENTISSAGE]

Chaque action preventive doit avoir un indicateur de succes mesurable (ex: MTTR reduit de X%, couverture de test augumentee de Y%).