La démo ne montre jamais cette partie. Un outil de vibe coding génère un bouton « Connecter votre Google Calendar » soigné en un seul prompt, et ça a l’air terminé. Ce que la démo passe sous silence, c’est tout ce qui se trouve entre le clic sur ce bouton et la synchronisation effective du calendrier : une application développeur enregistrée dans la console du fournisseur, des identifiants OAuth configurés, des redirect URIs définis, et parfois une étape de vérification de domaine qui n’a rien à voir avec la logique de votre app et tout à voir avec le fait de prouver que vous possédez le domaine sur lequel vous construisez.
C’est la partie du vibe coding pour laquelle il n’existe aucun prompt. Impossible de la décrire pour la contourner, car le fournisseur (Google, Slack, Stripe, peu importe) exige les mêmes étapes d’enregistrement d’un créateur solo que d’une équipe d’ingénierie.
Ce qu’implique vraiment « connecter votre calendrier »
Pour une intégration comme Google Calendar, il n’existe pas de clé API à simplement coller dans un champ de configuration. Le code généré a besoin d’une identité réelle, enregistrée auprès du fournisseur, avant de pouvoir demander à quiconque d’autoriser quoi que ce soit. En pratique, cela signifie :
- Créer une application développeur dans la console du fournisseur (Google Cloud Console, le tableau de bord des apps Slack, le portail développeur Stripe).
- Configurer les identifiants OAuth de cette application : un client ID et un secret qui identifient votre app auprès du fournisseur.
- Définir les redirect URIs qui correspondent exactement à l’endroit où le fournisseur doit renvoyer l’utilisateur après autorisation, jusqu’au protocole et à la barre oblique finale.
- Valider la vérification de domaine, lorsque le fournisseur exige la preuve que vous contrôlez le domaine sur lequel l’app tourne avant d’accorder un accès de niveau production.
- Sélectionner et demander les scopes, les permissions précises que l’app réclame, qui sont ensuite examinées (parfois par le fournisseur, parfois simplement par celui qui construit l’app dans l’urgence).
Rien de tout cela n’est de la logique applicative. C’est de l’administration de compte sur la plateforme de quelqu’un d’autre, et il faut le faire correctement avant qu’un seul événement de calendrier n’apparaisse dans l’interface générée.
Deux façons de se tromper sur les scopes, toutes deux mauvaises
Les scopes sont l’endroit où cela cesse d’être simplement fastidieux et commence à devenir risqué. Se tromper dans un sens ou dans l’autre produit un échec complètement différent.
Trop de scopes est l’échec de sécurité. Demander un accès Drive complet alors que la fonctionnalité n’avait besoin que d’événements Calendar en lecture seule n’est pas un raccourci, c’est un risque permanent : chaque fichier de ce compte devient désormais accessible via une autorisation dont l’app n’avait pas besoin. Il reste là, silencieux, jusqu’au jour où un token fuite ou une session est compromise, et à ce moment-là le rayon d’impact correspond à l’ensemble des scopes accordés, pas à la fonctionnalité réellement construite. C’est le même type de problème que les 45 % de code généré par IA porteur de vulnérabilités de classe OWASP : le code fonctionne bien et fait une démo parfaite, tandis que l’exposition reste en dessous, invisible jusqu’à ce que quelque chose tourne mal.
Trop peu de scopes est le mode d’échec silencieux. Manquer un seul scope requis et l’intégration ne lève pas d’erreur claire ; elle cesse simplement de fonctionner d’une manière difficile à diagnostiquer. Une synchronisation de calendrier qui ne renvoie rien, une notification Slack qui ne s’envoie jamais, un webhook Stripe qui se déclenche mais dont le handler ne peut pas lire le champ dont il a besoin. Un créateur non technique face à un résultat vide n’a aucun moyen de savoir si le bug vient du code généré, de la configuration des scopes, ou du côté du fournisseur, et l’IA ne peut pas inspecter l’autorisation OAuth pour le lui dire.
Obtenir la liste exacte des scopes, et la revérifier chaque fois que le périmètre de fonctionnalités change, est une compétence précise et étroite. Elle n’est pas couverte par le prompting « décrivez ce que vous voulez », car l’IA qui génère le code d’intégration ne contrôle pas ce que la console du fournisseur autorisera réellement.
Où finissent par vivre les identifiants
Une fois que la danse OAuth fonctionne, le client ID, le secret et les éventuels tokens d’accès doivent bien vivre quelque part. Ce « quelque part » est une véritable décision d’architecture, pas un détail. Tester l’intégration en local signifie que l’app a besoin de variables d’environnement pointant vers de vrais identifiants, et les créateurs non techniques qui ne savent pas gérer correctement les fichiers .env finissent régulièrement par écrire ces valeurs en dur directement dans le code. Des secrets codés en dur qui se retrouvent poussés par accident vers un dépôt GitHub public arrivent assez souvent pour que ce soit un mode d’échec documenté et nommé de toute la catégorie, pas une erreur rare. Une fois qu’un secret se trouve dans l’historique d’un dépôt public, le faire tourner et vérifier que rien n’a exploité la fenêtre d’exposition devient un travail de nettoyage à part entière, en plus de l’intégration que vous cherchiez à livrer.
De la plomberie, pas du produit
Cela vaut la peine d’être nommé pour ce que c’est : du travail d’infrastructure, pas la fonctionnalité que vous essayiez de construire. Personne ne se réveille avec l’envie de configurer un redirect URI. Le besoin métier était « afficher les prochains rendez-vous du client » ou « notifier l’équipe sur Slack quand un deal se conclut ». La console OAuth, la liste des scopes et le stockage des identifiants sont le coût incontournable pour y arriver sur une plateforme où chaque intégration se construit à partir de zéro, et ce coût augmente avec le nombre de services tiers que l’app touche, pas avec le niveau de finition de la fonctionnalité.
C’est exactement le terrain où une plateforme comme Softr est le bon outil pour le travail plutôt qu’un contournement. Ses connecteurs natifs pour Google Calendar, HubSpot, Stripe et autres outils métier similaires sont des applications OAuth pré-vérifiées et déjà approuvées : un créateur autorise son compte via un flux de connexion, et les scopes ainsi que le stockage des identifiants sont gérés côté serveur, entièrement hors du client, parce que Softr a déjà fait l’enregistrement console une fois pour tout le monde. Mais pour un portail client ou un outil interne dont le rôle est surtout de « synchroniser un calendrier et poster sur Slack », la taxe d’intégration est le genre de plomberie qu’il est plus rentable d’acheter comme infrastructure de plateforme que de réinventer projet par projet.
Ce compromis cesse d’avoir du sens dès l’instant où l’intégration elle-même devient le produit. Si vous câblez un fournisseur pour lequel personne n’a de connecteur, ou si vous avez besoin de contrôler le rafraîchissement des tokens et la gestion des erreurs, vous voulez posséder le flux OAuth plutôt que d’en hériter d’un autre. C’est du travail de développeur, et cela relève des outils de développeur : Cursor dans une vraie base de code où vous pouvez lire ce que font réellement les identifiants, ou Replit où la gestion des variables d’environnement et des secrets est native plutôt que rajoutée après coup. Aucun des deux ne supprime l’enregistrement console, parce que rien ne le fait. Ils vous mettent simplement en position de définir les scopes correctement et délibérément, plutôt que de les découvrir par essais et erreurs.
La boucle du fix aggrave cela avec le temps, elle ne l’améliore pas. Chaque ajustement de scope ou nouvelle intégration est un nouveau tour de configuration console, un nouveau redirect URI à définir exactement, et une nouvelle occasion d’accorder trop ou trop peu. C’est un coût qui s’accumule à chaque fonctionnalité ajoutée, ce qui correspond précisément à la forme du problème du Jour Deux : l’app qui faisait une démo impeccable le premier jour continue de générer du nouveau travail de plomberie à chaque fois qu’elle grandit.