원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Un employé non-développeur crée en trois jours une superbe application web grâce à des outils de vibe coding comme v0 ou Cursor. Le PDG, tout enthousiaste, propose immédiatement de la connecter à la base de données de production pour la mettre à disposition des clients. C'est le moment où les développeurs et le CTO suent à grosses gouttes. En ouvrant le code généré par l'IA, ils découvrent que la chaîne de connexion à la BDD (DSN) est directement intégrée au cœur d'un composant client, ou que des requêtes SQL sont exécutées sans la moindre validation.
Déployer cela tel quel sur un serveur de production n'est qu'une question de temps avant la catastrophe. Le rapport OWASP Top 10 for LLM Applications 2025 pointe d'ailleurs le privilège excessif du code généré par IA (LLM06) et le manque de validation des entrées (LLM05) comme les risques de sécurité les plus critiques. En réalité, 73 % des violations de sécurité des applications web exploitent l'absence de validation des entrées.
Pour préserver la productivité des non-développeurs tout en protégeant la base de données de l'entreprise, il est indispensable de placer une couche de contrôle solide entre le prototype et la BDD.
La première chose à faire est de bloquer le passage afin que l'application créée par un non-développeur ne puisse pas interroger directement la BDD. Il faut placer un gestionnaire de route serveur Next.js App Router en tant que proxy et valider les données entrantes en temps réel à l'aide de la bibliothèque Zod. La vérification de type de TypeScript ne fonctionne qu'au moment du développement ; elle n'empêchera pas le serveur de planter lorsqu'un véritable utilisateur enverra des données corrompues.
| Élément vérifié | Validation côté UI (Navigateur) | Couche proxy Zod côté serveur |
|---|---|---|
| Emplacement d'exécution | Navigateur du client | Runtime Serverless Vercel |
| Sécurité | Facilement contournable via les outils de développement | Blocage forcé sur le serveur pour protéger la BDD |
| Validation des données | Vérification superficielle du texte | Validation précise des types et des plages de valeurs au runtime |
| Gestion des échecs | Affichage d'un message d'avertissement à l'écran | Renvoi d'un HTTP 400 et enregistrement de l'erreur dans Sentry |
La méthode de mise en place est simple :
app/api/v1/customer-records/route.ts dans le projet.companyName fasse au moins 2 caractères, contactEmail respecte le format email, et employeeCount soit un entier positif.request.json() avec schema.parse(). N'insérez dans la BDD via l'ORM Prisma que les données validées, et en cas d'échec, renvoyez immédiatement une erreur 400 pour rejeter la requête.En plus de la validation au niveau de l'application, il faut également protéger la base de données elle-même. Si vous utilisez Supabase basé sur PostgreSQL, la configuration du Row Level Security (RLS) est la solution. Stockez les rôles utilisateurs dans raw_app_meta_data, géré uniquement par les administrateurs, au lieu de raw_user_meta_data, qui peut être manipulé par l'utilisateur, puis validez le JWT.
`sql
-- 1. Activation du RLS sur la table
ALTER TABLE public.enterprise_documents ENABLE ROW LEVEL SECURITY;
-- 2. Création de la fonction pour extraire le rôle utilisateur depuis le JWT
CREATE OR REPLACE FUNCTION get_user_role()
RETURNS text AS
LANGUAGE sql STABLE;
-- 3. Politique autorisant la lecture uniquement pour le même département ou les administrateurs
CREATE POLICY "Department Access Policy" ON public.enterprise_documents
FOR SELECT USING (
get_user_role() = 'admin' OR
department = (current_setting('request.jwt.claims', true)::json->'app_metadata'->>'department')
);
`
Grâce à cette configuration, même si un non-développeur laisse fuiter par erreur la clé de rôle de service (Service Role Key) dans le code, les documents confidentiels des autres départements ne seront jamais compromis.
Les outils d'IA étant conçus pour afficher rapidement un résultat à l'écran, ils écrivent souvent les clés d'API ou les chaînes de connexion DB à des endroits exposés au navigateur. L'erreur la plus fréquente consiste à ajouter le préfixe NEXT_PUBLIC_ n'importe où. Dans Next.js, les variables portant ce préfixe sont intégrées en texte clair dans les fichiers JavaScript envoyés au navigateur. Dès que vous créez une variable comme NEXT_PUBLIC_OPENAI_API_KEY, quiconque sait ouvrir les outils de développement (F12) peut récupérer votre clé d'API et l'utiliser à sa guise.
Il suffit de regarder l'incident de sécurité survenu en avril 2026 sur l'infrastructure Vercel. Des autorisations compromises sur des outils d'IA tiers intégrés ont exposé des variables d'environnement non masquées, contraignant de nombreuses équipes à passer la nuit à régénérer une à une leurs clés d'API et mots de passe de BDD.
Il est impossible pour un être humain de contrôler chaque détail manuellement. Il faut intégrer l'outil d'analyse statique Gitleaks dans GitHub Actions pour détecter et éliminer automatiquement ces fuites avant de fusionner le code.
`yaml
name: Security Scan
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
gitleaks-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install and Run Gitleaks
run: |
wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz
tar -xzvf gitleaks_8.18.0_linux_x64.tar.gz
sudo mv gitleaks /usr/local/bin/
gitleaks detect --source=. --verbose --redact --exit-code=1
public-env-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check Unsafe Public Keys
run: |
UNSAFE=(grep -rn "NEXT_PUBLIC_.*\(SECRET\|KEY\|PASSWORD\|TOKEN\|DSN\)" . || true)
if [ -n "UNSAFE" ]; then
echo "Sensible variable exposed to client found:"
echo "$UNSAFE"
exit 1
fi
`
Lorsque ce pipeline est en place, si un non-développeur insère une clé d'API dans le code source ou dans une variable NEXT_PUBLIC_ et pousse son code, le déploiement est automatiquement bloqué.
Lors de l'enregistrement des variables sur le tableau de bord Vercel, il convient également de bien séparer les environnements Development, Preview et Production. Pensez surtout à cocher l'option Sensitive Environment Variable. De cette façon, elles ne s'afficheront pas dans les logs de build et seront chiffrées pour empêcher tout copier-coller en clair depuis le tableau de bord.
Si les serveurs d'OpenAI ou d'Anthropic tombent en panne ou mettent du temps à répondre, l'ensemble des gestionnaires serverless se retrouvent en attente, provoquant des pannes en chaîne. Dans ce genre de situation, il faut installer un coupe-circuit (circuit breaker) avec la bibliothèque Node.js opossum.
`typescript
import CircuitBreaker from 'opossum';
async function callLLM(prompt: string) {
// Logique d'appel à l'API LLM
}
const options = {
timeout: 5000, // Considéré comme échec après 5 secondes
errorThresholdPercentage: 50, // Ouvre le circuit si le taux d'échec dépasse 50%
resetTimeout: 30000 // Réessaie après 30 secondes
};
const breaker = new CircuitBreaker(callLLM, options);
breaker.fallback(() => ({ error: "La réponse de l'IA est retardée. Veuillez réessayer dans un instant." }));
`
En cas de retard de réponse de l'API, un message d'information prédéfini est envoyé en 0,1 seconde, évitant ainsi le crash complet du service.
Pour qu'un créateur non-développeur soit immédiatement informé des pannes, connectez également Sentry à un webhook Slack.
`typescript
// app/api/webhooks/sentry-to-slack/route.ts
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
try {
const event = await request.json();
const webhookUrl = process.env.SLACK_INCOMING_WEBHOOK_URL;
if (!webhookUrl) return NextResponse.json({ error: 'Webhook manquant' }, { status: 500 });
const title = event.data?.issue?.title || 'Erreur système inconnue';
const issueUrl = event.data?.issue?.permalink || '#';
await fetch(webhookUrl, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
blocks: [
{
type: 'header',
text: { type: 'plain_text', text: '🚨 Erreur de production détectée' }
},
{
type: 'section',
text: { type: 'mrkdwn', text: `*Détail de l'erreur :*
${title}` }
},
{
type: 'actions',
elements: [
{
type: 'button',
text: { type: 'plain_text', text: 'Voir le rapport Sentry' },
url: issueUrl,
style: 'danger'
}
]
}
]
})
});
return NextResponse.json({ success: true });
} catch (err) {
return NextResponse.json({ error: 'Échec du Webhook' }, { status: 500 });
}
}
`
Si l'erreur s'aggrave jusqu'à provoquer un incident de niveau P1 où la page principale ne s'affiche plus, il n'est même pas nécessaire d'attendre un développeur. Vercel conserve l'intégralité des déploiements précédents, ce qui permet de revenir à l'état antérieur en quelques clics.
Il suffit d'attendre 30 secondes pour que le routage du domaine bascule sur la version précédente. En combinant la validation Zod, le scan Gitleaks et les procédures de rollback Vercel, vous pouvez laisser les non-développeurs créer des applications en toute liberté tout en dormant sur vos deux oreilles.