Tu peux être très content de Vercel côté DX et quand même te faire piéger côté confidentialité dès que tu utilises un outil « agentic ». Parce que là, on ne parle plus juste d’héberger un build et de servir des pages. On parle de code + conversations + télémétrie qui peuvent sortir de ton périmètre, et d’un programme d’entraînement IA avec une logique d’opt-in/opt-out qui dépend du plan.
L’objectif ici n’est pas de faire peur. C’est de te donner une lecture utile des CGU 2026 de Vercel, et surtout une méthode terrain pour éviter la phrase que personne ne veut prononcer : « oui, on a collé le repo client dans un agent cloud sans cadrage ». Si tu es freelance, studio, ou juste la personne qui signe (ou subit) les choix outillage, c’est typiquement le genre de détail qui finit en incident ou en discussion contractuelle pénible.
Ce que Vercel dit collecter quand tu utilises des fonctionnalités IA « agentic »
Dans sa mise à jour de mars 2026, Vercel explicite ce qui entre dans le périmètre des fonctionnalités « agentic » (dont Vercel Agent) et du programme optionnel d’entraînement IA. Le point important, c’est la nature des données mentionnées, parce qu’elle change complètement ta lecture du risque.
Il est question de code et de chats avec Vercel Agent. Dit autrement, il faut arrêter de penser « je discute avec une IA » comme si c’était une conversation abstraite. Dans un workflow agent, tu finis vite par coller des extraits de code, des chemins de fichiers, des logs, des bouts de config, parfois des morceaux de tickets ou de messages internes. Et à partir du moment où ça circule, tu dois le traiter comme un flux de données potentiellement sensible.
Vercel mentionne aussi de la télémétrie liée aux builds/déploiements et des erreurs. Ce n’est pas « juste des métriques ». Dans la vraie vie, une erreur peut contenir un payload, une URL interne, un bout de stacktrace avec des noms de classes qui trahissent ton domaine, ou carrément des valeurs qui n’auraient jamais dû se retrouver là. C’est souvent là que les fuites « bêtes » arrivent.
Ce que je retiens côté praticien : dès que tu actives (ou utilises) ce genre de fonctionnalité, tu dois considérer que tu es en train d’ouvrir un nouveau canal de sortie de données. Même si la plateforme est sérieuse, même si tu fais confiance, même si « tout le monde le fait ». Le sujet n’est pas moral. Le sujet est opérationnel.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Opt-in vs opt-out : le détail qui change tout selon ton plan Vercel
Le programme d’entraînement IA est décrit comme optionnel, mais la mécanique n’est pas la même pour tout le monde. D’après l’annonce Vercel (mars 2026), on a :
Hobby (y compris Trial Pro) : opt-in. Ça veut dire que tu n’es pas « embarqué » par défaut dans l’entraînement, mais ça veut aussi dire que tu peux l’activer volontairement, parfois sans mesurer ce que ça implique sur des projets de démo, des POC, ou des repos « pas si anodins ».
Pro : opt-out. Et là, le réflexe doit être immédiat : si tu es en Pro et que tu n’as jamais regardé le réglage, tu ne peux pas supposer que « c’est bon ». Opt-out veut dire que la responsabilité est sur toi. Ce n’est pas « mal », c’est juste un modèle où l’oubli coûte cher.
Enterprise : opt-out. Ça surprend souvent, parce qu’on associe Enterprise à « cadré par défaut ». En réalité, Enterprise te donne surtout les leviers (process, contrats, sécurité), mais il faut quand même les actionner. Et dans beaucoup de boîtes, l’Enterprise est géré par une petite équipe plateforme, pendant que les équipes produit branchent des features à droite à gauche. Le décalage entre ces deux mondes, c’est la zone de risque.
Le vrai piège, ce n’est pas de ne pas connaître les CGU. C’est de ne pas savoir quel plan est effectivement utilisé sur le projet qui t’intéresse. Entre l’orga de ton client, l’orga du studio, des comptes perso, des tests en Trial… ça se mélange vite. Et c’est justement quand « ça se mélange » que tu perds le contrôle.
Les fuites arrivent rarement par le “gros secret”, mais par le petit contexte
Quand on parle de confidentialité, tout le monde pense tout de suite « clé AWS » ou « token Stripe ». Oui, évidemment. Mais les vraies fuites qui font mal, je les vois plus souvent sur des choses moins spectaculaires.
Le premier classique, c’est le code client qui matérialise du savoir-faire. Une logique métier, une segmentation, un pricing rule, un algo d’attribution, un anti-fraude maison. Ce n’est pas un secret au sens crypto du terme, mais c’est exactement ce que le client ne veut pas voir partir dans un outil non cadré.
Le deuxième, c’est la conversation elle-même. Les gens racontent leur vie à un agent, parce que c’est pratique. « Le client X veut qu’on cache ça », « l’admin est sur telle route », « la prod est en feu depuis telle date ». En prestataire, c’est vite du confidentiel contractuel, même si techniquement ce n’est pas un secret d’infra.
Le troisième, ce sont les logs et erreurs. Une stacktrace qui embarque des paramètres, une URL interne, des IDs, des emails de test, un payload de webhook. Quand tu copies-colles ça dans un chat, tu viens de transformer un incident local en donnée partagée.
Donc oui, tu dois continuer à traquer les secrets. Mais si tu ne traites pas le « contexte » comme une donnée, tu vas te faire surprendre.
Ce que je mets en place en équipe avant d’utiliser un agent cloud sur du code client
Je préfère être clair : je ne veux pas interdire l’IA. Je veux un cadre qui évite les accidents et qui tient quand tu as 10 projets, 3 urgences et des gens qui onboardent. Le but, c’est que le process protège l’équipe même quand elle va vite.
La première chose, c’est un tour d’horizon des réglages dans l’orga Vercel. Pas une lecture théorique. Un check réel, daté, documenté en interne : qui est admin, quel plan est actif, et surtout quel est le statut du programme d’entraînement IA (opt-in/opt-out selon le plan). Si tu ne peux pas répondre en 2 minutes, tu n’as pas la maîtrise.
La deuxième, c’est une règle simple sur la séparation des périmètres. Un projet client sensible ne doit pas cohabiter avec ton bac à sable. Concrètement, je veux des orga distinctes quand c’est justifié, des accès minimaux, et une séparation nette des repos. L’objectif est bête : réduire les situations où quelqu’un teste Vercel Agent « pour voir »… mais sur le mauvais projet.
La troisième, c’est la discipline sur les secrets. Pas juste « ne commit pas de secrets ». Je parle d’un repo qui peut être partagé à une IA ou à un agent : tu dois assumer que tout ce qui est dans le repo finira un jour dans un prompt ou un log. Donc tu veux des .env propres, des .env.example sans valeurs sensibles, des variables injectées par l’environnement, et idéalement un scan automatique en CI qui te hurle dessus avant que le problème se propage.
#!/usr/bin/env bash
# Exemple minimaliste : refuser un commit qui contient des patterns de secrets évidents.
# Ce n'est pas magique, mais ça évite des boulettes.
set -e
FILES=$(git diff --cached --name-only)
# Patterns volontairement simples. À adapter.
PATTERN='(sk_live_|AKIA[0-9A-Z]{16}|-----BEGIN (RSA|OPENSSH) PRIVATE KEY-----|xox[baprs]-)'
if git diff --cached -U0 -- $FILES | grep -E "$PATTERN" >/dev/null 2>&1; then
echo "[blocked] Possible secret detected in staged changes."
echo "Check your diff, move secrets to env vars, then retry."
exit 1
fi
La quatrième, c’est une habitude de rédaction quand tu utilises l’agent. Tu ne colles pas des dumps entiers. Tu fais des extraits minimaux. Tu remplaces les IDs, les emails, les domaines internes. Et si tu dois analyser un log, tu le nettoies avant. C’est du « boulot en plus », mais c’est littéralement ce qui différencie une équipe qui contrôle ses flux d’une équipe qui s’en remet à la chance.
Enfin, je veux un minimum de traçabilité. Si l’équipe utilise Vercel Agent, je veux que ça se voie : un canal interne, un doc, une règle « pas d’usage sur tel type de projet sans validation ». Pas pour fliquer, pour éviter que ce soit invisible. Ce qui est invisible ne se gère pas.
Freelance / studio : ce que tu dois cadrer dans ton contrat (sinon tu prendras le choc)
Si tu bosses pour des clients, tu peux être sûr d’une chose : le jour où le sujet sort sur la table, ce sera après coup, au pire moment. Un audit sécurité, une demande DSI, un appel paniqué, ou un client qui « découvre » que tu utilises des outils IA sur son code.
Ce que je fais, c’est cadrer le terrain avant. Je ne promets pas « zéro outil cloud ». Je promets une approche : confidentialité, maîtrise des sous-traitants, et options claires. L’essentiel est d’avoir une clause qui dit que tu peux utiliser des outils d’assistance (dont des fonctionnalités IA), mais avec des paramètres et des restrictions, et surtout avec la possibilité de désactiver l’entraînement IA si le client l’exige.
Dans les missions un peu sérieuses, il faut aussi arrêter de faire semblant que « c’est juste un hébergeur ». Si tu déploies chez Vercel, Vercel devient un sous-traitant au sens large. Et si tu ajoutes une brique agentic, tu ajoutes un usage particulier de données. Donc tu veux un passage sur les sous-traitants et sur le fait que l’hébergement et certains outils associés peuvent traiter des données techniques (code, logs, télémétrie). Ça ne rend pas le sujet parfait, mais ça évite le mensonge par omission.
Le dernier point, c’est l’explicite. Si ton client est sensible, tu proposes noir sur blanc une option « opt-out » (ou « pas d’entraînement IA »), et tu le notes. La plupart des conflits viennent d’un flou. Or là, le flou est évitable.
Plan B : quand tu dois rester local, isolé, ou “air-gapped” (et que tu veux quand même un agent)
Il y a des contextes où la meilleure décision est simple : tu ne mets pas le code dans un agent cloud. Secteur régulé, contraintes IP fortes, sécurité interne stricte, ou juste un client qui ne veut pas. Ça arrive, et ce n’est pas un drame.
Le plan B, ce n’est pas « on n’utilise pas d’agent ». Le plan B, c’est de basculer sur un workflow plus isolé : agent local, modèle local ou self-hosted, ou au minimum une séparation drastique entre ce qui peut sortir (doc publique, code non sensible) et ce qui ne sort pas. Ce n’est pas aussi confortable, mais c’est souvent le bon compromis.
Dans la pratique, ce que je vise c’est un mode « deux vitesses ». D’un côté, un agent cloud pour accélérer sur le squelette, la plomberie, les tâches sans enjeu business. De l’autre, un périmètre fermé pour tout ce qui touche au cœur métier et aux données. Le plus dur n’est pas technique. Le plus dur, c’est de faire respecter la frontière quand la pression monte.
Mon avis (tranché) : le vrai risque, c’est l’outil IA “activé” sans décision
Je n’ai pas de problème avec Vercel qui clarifie ses règles. Au contraire, c’est exactement ce que je veux voir : des termes explicites, des plans qui définissent un régime, et un programme d’entraînement présenté comme optionnel.
Le risque, c’est l’équipe qui adopte l’agent comme un gadget de productivité, sans décider du régime de données, sans vérifier l’opt-in/opt-out de son plan, et sans aligner ça avec ce qu’elle a promis à ses clients. Et ça, c’est un problème d’hygiène, pas un problème de plateforme.
Si tu dois retenir une seule règle : tant que tu n’as pas vérifié et documenté le statut opt-in/opt-out et les réglages associés, tu considères que c’est “non maîtrisé”. Ensuite tu choisis : tu assumes, tu désactives, ou tu isoles. Mais tu choisis.
