La plupart des portfolios de développeurs sont des sites statiques. Le mien a des SLO.
Il ne s'agit pas de sur-ingénierie. Il s'agit de démontrer une compétence spécifique difficile à montrer en entretien : la maturité opérationnelle.
Ce que signifie « Portfolio de qualité production »
Mon site portfolio (sageideas.dev) dispose de :
- Objectifs SLO : 99,9 % de disponibilité du tableau de bord, fraîcheur de la télémétrie <24h, temps de réponse P95 <500ms
- Exercices d'incident : 4 scénarios de défaillance testés avec des réponses documentées
- Limitation de débit WAF : Web ACL CloudFront avec preuve de simulation d'attaque
- Fédération OIDC : GitHub Actions → AWS sans identifiants statiques
- Télémétrie de qualité : Tableau de bord en direct extrayant les artefacts CI en temps réel
- Reçus de sécurité : Politiques IAM, modèles de menace et preuves pour chaque affirmation
Pourquoi se donner cette peine ?
Parce que l'écart entre « je sais construire des choses » et « je sais faire fonctionner des choses » est l'espace où se situent les postes seniors.
Les ingénieurs juniors construisent des fonctionnalités. Les ingénieurs de niveau intermédiaire construisent des systèmes. Les ingénieurs seniors exploitent les systèmes — ils réfléchissent aux modes de défaillance, au rayon d'explosion, au coût, à la conformité et à ce qui se passe à 3h du matin.
En traitant mon portfolio comme de la production, je montre :
- Je pense à l'échec avant qu'il ne survienne — chaque dépendance externe a une solution de repli
- Je mesure ce qui compte — des SLO, pas des métriques de vanité
- Je documente pour la personne suivante — runbooks, playbooks, documents d'architecture
- Je ne fais pas de compromis sur la sécurité — même pour un site portfolio
Le modèle d'exercice d'incident
Chaque trimestre, j'exécute 4 scénarios :
| Scénario | Réponse | Statut |
|---|---|---|
| Limites de débit de l'API GitHub | Repli en mode snapshot | Testé |
| Artefact CI manquant | Analyse des exécutions récentes, dégradation gracieuse | Testé |
| Non-concordance du jeton proxy AWS | Alarme CloudWatch, auto-dégradation | Testé |
| Objet S3 manquant | Échec fermé, aucune fuite de secrets | Testé |
Chaque exercice suit : détection → triage → atténuation → vérification → documentation
Le rapport d'exercice est accessible publiquement dans ma bibliothèque d'artefacts.
Ce que les recruteurs remarquent
Quand je passe des entretiens pour des postes senior/staff, je ne parle pas du design de mon portfolio. Je parle de son exploitation :
- « Voici mon tableau de bord SLO. Nous sommes à 99,94 % ce mois-ci. »
- « Voici un test de limitation de débit WAF que j'ai effectué la semaine dernière. Les 429 se déclenchent à 100 req/5min. »
- « Voici la politique IAM. La Lambda a exactement une permission : s3:GetObject sur une clé. »
Cela change la conversation de « savez-vous coder ? » à « savez-vous faire fonctionner des systèmes ? » — ce qui est ce que les postes à plus de 200 000 $ exigent réellement.
Comment faire cela vous-même
Vous n'avez pas besoin d'AWS. Commencez petit :
- Définissez un SLO — « Mon site aura 99 % de disponibilité ce mois-ci. » Surveillez-le.
- Ajoutez une porte de qualité — Lighthouse CI dans votre pipeline de déploiement. Échouez la build si les performances chutent.
- Documentez un mode de défaillance — « Si ma clé API expire, que se passe-t-il ? » Écrivez la réponse.
- Exécutez un exercice d'incident — Cassez réellement quelque chose intentionnellement et entraînez-vous à répondre.
L'objectif n'est pas la perfection. C'est de démontrer que vous pensez à la production, pas seulement au développement.
Système connexe : Ce qu'un studio natif IA construit réellement explique pourquoi le portfolio est traité à la fois comme surface produit, système d'exploitation et boucle de croissance.
