Le bouton est juste là, sous mon curseur. « Dupliquer ce scénario. » Un clic dans Make, trente secondes, et j’ai une copie complète devant moi. Ma main hésite une seconde de trop.
J’ai un scénario qui zippe un plugin Claude et le dépose dans un dossier Google Drive à chaque nouvelle release GitHub. Il tourne pour substackos depuis un moment, tranquille, en arrière-plan. Je ne le regarde même plus.
Puis je lance comment-systematiser, un deuxième plugin. Et lui aussi, il a besoin d’exactement la même mécanique : une release GitHub qui déclenche, un zip qui se crée, un dépôt sur Drive. Même logique, un nom de repo différent, un dossier Drive différent.
Le plus simple, sur le moment, ça aurait été de dupliquer. Changer deux ou trois valeurs codées en dur dans la copie, et basta. Honnêtement, la flemme a failli gagner.
Sauf que je sais très bien comment ça finit, un scénario dupliqué. Le jour où je trouve un bug dans cette logique, ou que je veux l’améliorer, je dois le corriger deux fois. Dans deux scénarios presque identiques, en espérant ne pas en oublier un au passage. Et si un troisième plugin arrive un jour ? Trois scénarios à tenir à jour, à la main. Pour toujours.
Alors j’ai fait l’inverse. Dans Make, ça a un nom : un scénario enfant qui démarre avec le module Start a subscenario, lequel définit noir sur blanc les entrées attendues. Et un ou plusieurs scénarios parents qui le rappellent avec le module Call a subscenario, chacun avec ses propres valeurs.
J’ai gardé un seul scénario enfant, [leny.media] Template - Create Zip Plugin. Il fait tout le travail. Il attend quatre entrées : le nom du repo, le nom du zip, l’ID du dossier Drive, le tag de la release. Et c’est lui, et lui seul, qui zippe et qui dépose sur Drive.
Ensuite, j’ai créé deux scénarios parents, tout légers : [substackos] Create Zip Plugin et [comment-systematiser] Create Zip Plugin. Chacun se déclenche sur sa propre release GitHub.
Le jour où je corrige un bug, je le corrige une fois, dans le scénario enfant, et les deux projets en profitent tout de suite. Un scénario à tenir à jour, pas deux.
Ça, c’est mon histoire avec Make. En fait, le réflexe dépasse largement Make.
Voici ce que je retiens : chaque fois que tu copies-colles un bout de logique d’un scénario à un autre, tu ne gagnes pas de temps. Tu l’empruntes à toi-même, dans le futur, avec des intérêts. Un bug, une évolution, un simple changement de format. Et tu dois le refaire dans chaque scénario presque identique, en espérant les avoir tous retrouvés. Isoler ce comportement dans un scénario enfant, avec une vraie fiche à remplir plutôt que des valeurs codées en dur. Ça le rend corrigeable et améliorable à un seul endroit. C’est exactement le réflexe « fonction réutilisable » qu’on a en dev depuis toujours, transposé au no-code.
C’est ce réflexe que je fais pratiquer dans le nouveau tuto du plugin comment-automatiser : make-subscenario. L’exemple est volontairement plus simple que mon histoire de zip et de Drive, pour que tu puisses le suivre sans connaître ni GitHub ni Google Drive. Tu construis d’abord un scénario enfant, « Template - Journaliser ». Il reçoit trois entrées, pas une de plus. Un nom de projet, un type d’événement, un détail. Il formate un message et l’envoie vers une adresse de test sur webhook.site. Ce site garde une trace de tout ce qu’on lui envoie, pour vérifier que ça part bien. Ensuite, tu construis deux scénarios parents, avec deux déclencheurs différents : un webhook, puis un déclenchement planifié ou manuel. Les deux appellent ce même enfant, avec des noms de projet différents à chaque fois.
Chaque étape est vérifiée avant de passer à la suivante. Et la dernière ne se contente pas d’un « oui, ça marche » sur parole : il faut une vraie preuve que le scénario enfant a tourné deux fois, avec deux payloads différents.
Aujourd’hui, quand j’ouvre Make et que je vois « Dupliquer » sous mon curseur, je m’arrête deux secondes avant de cliquer. Et toi, combien de fois tu as copié-collé un bout de logique (un scénario, un script, un prompt tapé à l’arrache) en te disant que tu remettrais ça au propre « plus tard » ? Réponds à cet email, raconte-moi ta version. Je suis curieux de savoir si je suis vraiment le seul.