1️⃣ Test‑Driven Development (TDD)

On écrit les tests avant le code.

Cycle classique :

1. écrire un test qui échoue
2. écrire le code minimum pour le faire passer
3. refactoriser

Cycle appelé Red → Green → Refactor

Avantages :

• code très testable
• moins de bugs
• architecture plus propre

Outils :

• Python : pytest
• C# : xUnit, NUnit
• JS : Jest

---

2️⃣ Behavior‑Driven Development (BDD)

Extension du TDD orientée comportement utilisateur.

On décrit le comportement avec un langage quasi naturel.

Exemple :

Given user is logged in
When user clicks checkout
Then order is created

Outils :

• Cucumber
• SpecFlow (.NET)
• Behave (Python)

Format Gherkin.

---

3️⃣ Acceptance Test‑Driven Development (ATDD)

Variante du BDD.

Les tests d’acceptation métier sont écrits avant le développement.

Participants :

• développeurs
• QA
• métier

But : s’assurer que la fonctionnalité correspond au besoin métier.

---

4️⃣ Domain‑Driven Development (DDD)

Approche architecturale.

On conçoit le logiciel autour du domaine métier.

Concepts :

• Entities
• Value Objects
• Aggregates
• Repositories
• Bounded Context

Très utilisé pour :

• microservices
• architectures complexes

---

5️⃣ Model‑Driven Development (MDD)

On part de modèles UML ou abstractions, puis on génère le code.

Exemple :

UML → génération code Java / C#

Utilisé dans :

• systèmes industriels
• systèmes embarqués

---

6️⃣ Specification‑Driven Development (SDD)

Le développement est guidé par une spécification formelle.

Exemple :

• OpenAPI
• contrats d’API
• interface contract

Exemple API :

OpenAPI → génération client + serveur

---

7️⃣ API‑Driven Development

Très utilisé pour les microservices.

On commence par définir l’API :

OpenAPI / Swagger

Ensuite :

• front
• backend

s’alignent dessus.

---

8️⃣ Contract‑Driven Development

Basé sur des contrats entre services.

Exemple :

Consumer → définit contrat
Provider → doit respecter contrat

Outils :

• Pact
• Spring Cloud Contract

---

9️⃣ Security‑Driven Development

La sécurité guide le design.

On part de :

• threat model
• attaques possibles

Puis on code.

Très utilisé pour :

• fintech
• défense
• blockchain

---

🔟 Data‑Driven Development

Les décisions sont prises à partir des données.

Exemple :

• A/B testing
• analytics
• télémétrie

---

Autres variantes

On rencontre aussi :

• UI‑Driven Development
• UX‑Driven Development
• Feature‑Driven Development (FDD)
• Performance‑Driven Development
• Event‑Driven Development

---

Les plus utilisés en pratique

Les 5 plus répandus :

1. TDD
2. BDD
3. DDD
4. API‑Driven Development
5. Contract‑Driven Development

Google Cloud a récemment envoyé un email aux utilisateurs pour les alerter sur les risques liés à une mauvaise gestion des clés d’API et des comptes de service. Les tendances récentes en matière de cybersécurité montrent que les identifiants à longue durée de vie et les mauvaises pratiques de sécurité restent une menace majeure pour les environnements cloud.

Dans cet article, nous allons détailler les recommandations de Google pour sécuriser vos clés d’API et comptes de service, ainsi que les bonnes pratiques à adopter pour éviter les compromissions.

---

1. Sécuriser le Cycle de Vie des Identifiants

✅ Ne jamais stocker les clés dans le code ou le contrôle de version

• Problème : Les clés d’API et les clés de compte de service ne doivent jamais être commitées dans un dépôt Git (GitHub, GitLab, Bitbucket, etc.).
• Solution :
  • Utiliser Google Secret Manager pour injecter les identifiants uniquement à l’exécution.
  • Configurer des variables d’environnement sécurisées dans votre CI/CD (GitHub Actions, GitLab CI, Cloud Build).

✅ Désactiver les clés dormantes

• Problème : Les clés inutilisées depuis plus de 30 jours représentent un risque inutile.
• Solution :
  • Auditer régulièrement les clés actives via Google Cloud Console ou gcloud CLI.
  • Supprimer les clés inutilisées pour réduire la surface d’attaque.

✅ Restreindre les clés d’API

• Problème : Une clé d’API non restreinte peut être utilisée pour appeler n’importe quelle API Google Cloud, ce qui augmente les risques en cas de fuite.
• Solution :
  • Limiter les API autorisées (ex : uniquement Maps JavaScript API).
  • Appliquer des restrictions d’environnement :
    • Adresses IP (autoriser uniquement certaines plages).
    • Référents HTTP (limiter aux domaines autorisés).
    • Bundle IDs (pour les applications mobiles).

✅ Appliquer le principe du moindre privilège

• Problème : Les comptes de service avec des permissions excessives augmentent les risques en cas de compromission.
• Solution :
  • Utiliser IAM Recommender pour identifier et supprimer les permissions inutilisées.
  • Ne jamais attribuer le rôle Owner ou Editor à un compte de service, sauf si absolument nécessaire.

✅ Imposer une rotation automatique des clés

• Problème : Les clés statiques peuvent être compromises sans que vous le sachiez.
• Solution :
  • Configurer la politique iam.serviceAccountKeyExpiryHours pour imposer une durée de vie maximale (ex : 90 jours).
  • Si possible, désactiver la création de nouvelles clés avec iam.managed.disableServiceAccountKeyCreation.

---

2. Renforcer les Sauvegardes Opérationnelles

✅ Mettre à jour les contacts essentiels

• Problème : En cas d’incident de sécurité, Google doit pouvoir contacter rapidement les bonnes personnes.
• Solution :
  • Vérifier et mettre à jour les contacts essentiels dans Google Cloud Console (IAM & Admin > Essential Contacts).
  • S’assurer que les alertes critiques (sécurité, facturation) sont envoyées aux bonnes adresses email.

✅ Configurer des alertes de facturation et d’anomalies

• Problème : Une hausse soudaine de consommation peut indiquer une compromission de clé.
• Solution :
  • Activer les alertes de budget dans Google Cloud Billing.
  • Configurer des alertes d’anomalies pour détecter les pics d’utilisation inhabituels.
  • Utiliser Cloud Monitoring pour surveiller les activités suspectes.

---

3. Outils et Commandes Utiles

🔧 Auditer les clés de compte de service

# Lister les clés de compte de service
gcloud iam service-accounts keys list --iam-account=SA_EMAIL@PROJECT_ID.iam.gserviceaccount.com

# Supprimer une clé
gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_EMAIL@PROJECT_ID.iam.gserviceaccount.com

🔧 Vérifier les restrictions d’une clé d’API

# Lister les clés d'API
gcloud alpha services api-keys list

# Voir les restrictions d'une clé
gcloud alpha services api-keys get-key-string API_KEY

🔧 Configurer une politique de rotation des clés

# Définir une durée de vie maximale (ex : 90 jours)
gcloud resource-manager org-policies enable-enforce \
    iam.serviceAccountKeyExpiryHours --organization=ORG_ID --duration=2160h

---

Conclusion : Adopter une Approche Zero Trust

Google insiste sur l’importance d’une stratégie de sécurité unifiée pour protéger vos identifiants cloud. En suivant ces bonnes pratiques, vous réduisez considérablement les risques de fuites de clés, d’accès non autorisés et de compromissions.

🔹 Checklist de Sécurité

Action	Statut
❌ Ne jamais commiter les clés dans Git	✅/❌
🔄 Désactiver les clés inutilisées (>30 jours)	✅/❌
🔒 Restreindre les clés d’API (IP, API, référents)	✅/❌
🛡️ Appliquer le moindre privilège (IAM Recommender)	✅/❌
🔄 Imposer une rotation automatique des clés	✅/❌
📧 Mettre à jour les contacts essentiels	✅/❌
💰 Configurer des alertes de budget et anomalies	✅/❌