# Vibe coding : usages et limites

Taiga Learning · Fiche d’exercice
https://taiga.training/fr/lessons/vibe-coding/

Utilisez des informations fictives ou approuvées. Ne placez pas de secrets dans cette fiche.

## Objectifs d’apprentissage
- Distinguer l’exploration d’une décision de mise en production.
- Repérer les responsabilités absentes d’une démonstration convaincante.
- Définir un cadre sûr pour une première expérimentation.

## Exercice
Choisissez une fonctionnalité présentée lors d’une démonstration récente.
1. Notez un résultat que la démonstration a établi.
2. Notez trois questions encore ouvertes.
3. Attribuez chaque question à un responsable.
4. Indiquez un contrôle précis capable de détecter chaque défaillance possible.
Ne remplacez pas un contrôle précis par la consigne « sécurisez l’application ».

## Votre réponse
- Scénario et périmètre :
- Hypothèses et questions ouvertes :
- Réponse ou décision proposée, avec justification :

## Vérifier votre réponse
| Affirmation ou critère | Preuve ou test | Résultat ou lacune | Responsable |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Action suivante
- Action, responsable et date :
- Quand réexaminerez-vous cette réponse ?

## Principe à retenir
Donnez aux équipes les moyens de prototyper avec des données synthétiques. Vérifiez la plateforme et l’application avant d’autoriser des données confidentielles ou l’accès à des API réelles.

## Sources
- [NIST: Secure Software Development Framework 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Lovable: Security best practices](https://docs.lovable.dev/tips-tricks/security-best-practices)
- [OWASP: Broken Object Level Authorization](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/)
- [Stripe: Idempotent requests](https://docs.stripe.com/api/idempotent_requests)

Cette fiche sert à apprendre. La remplir n’autorise pas à elle seule une modification en production.