Ton app travaille à 2h du matin. Toi, tu dors.
Au début, quand on exécutait une macro VBA sur un fichier Excel, le code tournait quand je le lançais. Il s'arrêtait quand je fermais mon ordinateur. Exactement comme une lampe de bureau. Tu appuies sur l'interrupteur, ça s'allume. Tu pars, tu éteins. C'est logique, c'est rassurant, c'est aussi profondément limitant.
Tous mes outils avaient besoin de moi pour respirer.
Pas de moi au sens stratégique. Au sens physique, littéral. Moi présente, les outils vivants. Moi absente, les outils morts.
Jusqu'ici, ton code dort quand tu dors
C'est le cas de tout ce qu'on a construit depuis le début de cette série.
Le serveur local dont on a parlé dans les premiers articles, le fameux npm run dev qu'on lance dans son terminal, il tourne tant que le terminal est ouvert. Ferme l'onglet, il s'arrête. Ferme l'ordinateur, il s'arrête. Coupe le wifi, il s'arrête. C'est sa nature : il dépend de ta machine, de ta présence, de ton électricité.
Pour un prototype qu'on teste seule dans son coin, c'est suffisant. Pour un outil qu'on veut voir travailler la nuit, récupérer des données à heure fixe, envoyer des alertes le dimanche matin, ça ne tient pas.
La question est donc : est-ce qu'il existe un endroit où mon code pourrait vivre sans moi ? (je ne veux pas vous spoiler, mais oui)
La réponse, c'est Supabase qui l'a. Et plus précisément, l'onglet que j'avais vu sans vraiment le regarder : Edge Functions.
Stanley à 2h du matin
Stanley, c'est le projet où les Edge Functions ont pris tout leur sens pour moi. Un outil interne initialement construit pour gérer un suivi commercial, branché notamment sur HubSpot, l'outil de gestion de contacts et de pipeline de vente qu'on utilisait côté business.
Le problème concret : je voulais que Stanley soit toujours à jour. Que chaque matin, quand quelqu'un ouvre l'outil, les données soient fraîches. Pas celles d'avant-hier, pas celles d'il y a trois jours. Celles de la nuit.
Sauf que synchroniser HubSpot avec ma base de données, ça veut dire lancer un script. Et lancer un script, jusqu'ici, ça voulait dire être là.
Ce que la fonction fait, concrètement
J'ai demandé à Claude faire une Edge Function. Un bout de code qui va frapper à la porte de HubSpot, récupère les contacts et les deals mis à jour depuis la dernière sync, nettoie ce qui doit l'être, et range tout ça proprement dans la base de données de Stanley.
Le code en lui-même n'est pas le sujet de cet article. Ce qui m'intéresse ici, c'est où il vit et comment il se déclenche.
Il vit chez Supabase. Pas sur mon MacBook, pas sur un serveur que j'aurais loué et configuré. Chez Supabase, dans l'onglet Edge Functions de ma console. Supabase en prend soin, le maintient disponible, s'assure qu'il peut répondre quand on l'appelle.
Et il se déclenche à 2h du matin. Tous les jours. Grâce à un cron.
Verifier ses logs
Le matin, j'ouvre mes logs.
Les logs, c'est le journal de bord de la nuit. Chaque fois que la fonction s'exécute, chaque fois qu'elle traite un contact, chaque fois qu'elle rencontre une erreur, elle écrit une ligne. Tout est daté, tout est horodaté, tout est là.
Ce que je lis le matin ressemble à ça : 2h17, déclenchement. 2h17, connexion HubSpot établie. 2h18, 47 contacts traités. 2h18, 3 deals mis à jour. 2h19, sync terminée.
Je n'étais pas là. Je dormais. Et pourtant quelque chose que j'ai construit a travaillé, a pris des décisions que j'avais anticipées, a fait ce que j'aurais fait si j'avais été là à 2h du matin à cliquer dans HubSpot.
C'est un peu comme trouver un mot sur la table de cuisine le matin, écrit par quelqu'un qui serait passé pendant la nuit. Sauf que ce quelqu'un, c'est moi, la veille, qui ai structuré la logique.
Deux mots à disjoindre : Edge Function et cron
Il y a deux choses distinctes dans ce que je viens de décrire, et il vaut la peine de les séparer clairement.
La première, c'est l'Edge Function. On en a parlé à l'article 8, dans un contexte différent : une Edge Function peut être déclenchée par une requête, comme quand un formulaire envoie des données et que la fonction les reçoit et les traite. Elle vit chez Supabase, pas sur ta machine. Tu peux la déclencher à la demande, comme on appuie sur un bouton.
Mais on peut aussi lui donner une horloge. Et cette horloge, c'est le cron.
Le cron, c'est un format d'instruction très ancien dans le monde informatique, qui dit simplement : déclenche-toi à telle heure, tel jour, telle fréquence. Tous les jours à 2h du matin, toutes les heures, tous les lundis à 8h. On lui donne le rythme, il s'en souvient, il respecte.
J'ai réglé mon cron pour Stanley comme on règle un minuteur de four. Tu poses le plat, tu règles, tu pars faire autre chose. Le four fait son travail. Tu n'as pas besoin d'être là pour surveiller la résistance chauffer.
La différence, c'est que mon minuteur de four ne rate jamais une nuit. Même le week-end. Même quand je suis en vacances. Même quand j'ai oublié que j'avais un outil qui s'appelle Stanley.
Ce que ça change quand on bosse seule
Je n'ai pas d'équipe ops. Pas de développeur en astreinte. Pas de serveur maintenu par quelqu'un d'autre quelque part. Je suis seule, et mes outils n'ont que moi.
Avant les Edge Functions avec cron, ça voulait dire que mes outils ne travaillaient que quand je travaillais. Que si je voulais une sync fraîche le lundi matin, il fallait que je la lance le lundi matin. Ou le dimanche soir. Ou que je mette un rappel dans mon agenda pour ne pas oublier.
Depuis que Stanley sync HubSpot chaque nuit, j'ai l'impression d'avoir une toute petite équipe de nuit. Silencieuse, régulière, qui ne prend pas de vacances et ne rate pas ses horaires.
Pour être précise : ce n'est pas moi qui suis remplacée. La logique, c'est moi qui l'ai écrite. Les décisions sur quoi synchroniser, comment nettoyer les données, quoi ignorer, c'est moi qui les ai prises. Ce qui est absorbé, c'est la tâche mécanique et répétitive : aller chercher, copier, ranger. Ça, je n'avais aucune valeur ajoutée à le faire à la main chaque matin.
J'ai écrit la logique une fois. Elle tourne sans moi. C'est ça, la bascule.
Pas "l'IA fait à ta place". Pas "tu n'as plus rien à faire". Tu écris ce que tu veux que ça fasse, une fois, soigneusement. Et ensuite ça le fait.
Pour quelqu'un qui travaille seule, c'est une différence de nature, pas de degré. Ce n'est pas juste "gagner du temps". C'est décorréler ta présence physique du fonctionnement de tes outils. Ton app peut traiter des données un dimanche à 2h du matin pendant que tu dors sous ta couette. C'est une chose que je n'aurais pas pu dire il y a deux ans.
Un piège à rat qui peut planter sans bruit
Il y a une histoire qui mérite d'être racontée pour équilibrer.
Un matin, j'ouvre mes logs comme d'habitude. À la place des lignes habituelles, une erreur. La fonction a tenté de se connecter à HubSpot à 2h17, comme prévu. Mais HubSpot a renvoyé une erreur d'authentification. La sync n'a pas eu lieu. Les données de la veille n'ont pas été mises à jour.
Pas de catastrophe. Pas de données perdues. Mais une nuit de sync manquée, et je ne l'avais appris qu'en ouvrant mes logs le matin.
C'est ça, l'autre face de l'histoire.
Une edge function qui tourne sans surveillance, c'est aussi une edge function qui peut planter sans surveillance. Elle ne vient pas te taper sur l'épaule pour te dire que quelque chose s'est mal passé. Elle écrit dans ses logs, et si tu ne les regardes pas, tu ne sais pas.
J'ai une image pour ça : le piège à rat posé dans le garage. Tu sais qu'il est là, tu sais qu'il fait son travail, mais si tu ne vas pas vérifier de temps en temps, tu ne sais pas ce qui s'y est passé. Et si le piège s'est refermé sur rien, ou sur quelque chose d'inattendu, tu l'apprends en retard.
Les logs matinaux sont devenus un rituel. Deux minutes, pas plus. Je parcours les lignes, je vérifie que la nuit s'est bien passée, je referme. Si tout est vert, je continue ma journée. Si quelque chose a planté, je sais pourquoi et je peux corriger avant que ça affecte quoi que ce soit.
Ce n'est pas une contrainte. C'est le prix normal d'un outil qui travaille la nuit : tu vérifies le matin que la nuit s'est bien passée.
La prochaine étape : les clés sous le paillasson
Quand j'ai branché ma fonction Stanley sur HubSpot, j'ai buté sur un problème que je n'avais pas anticipé.
Pour que ma fonction puisse entrer dans HubSpot, récupérer des données, lire des contacts, il faut qu'elle ait la permission. Et cette permission, HubSpot la donne sous forme d'une clé, un token d'accès. Une longue chaîne de caractères qui prouve que c'est bien moi qui envoie la requête.
La question : où est-ce qu'on met cette clé ?
La réponse naïve, c'est de la coller dans le code. Directement, en clair, comme on note un code wifi sur un post-it collé sous la box. Pratique. Terriblement risqué. Si ton code est un jour visible par quelqu'un d'autre, si tu le partages, si tu l'exportes, la clé part avec.
C'est exactement la clé sous le paillasson. Tout le monde sait que c'est là. C'est précisément ce qu'on ne veut pas faire.
Supabase a une solution pour ça. On appelle ça les secrets. Ce sont des variables stockées de façon sécurisée dans ta console Supabase, que ta fonction peut lire au moment où elle s'exécute, sans que la clé n'apparaisse jamais en clair dans ton code.
C'est le sujet de l'article suivant.