Un parseur cron, Base64, un formateur JSON, l'encodage d'URL et huit autres. Tout est calculé dans votre navigateur, donc rien de ce que vous collez n'atteint notre serveur.
Nous venons de publier une poignée de petits utilitaires sur /tools : un parseur d’expressions cron qui montre les cinq prochaines exécutions, l’encodage Base64, un formateur JSON, l’encodage pourcent des adresses et huit autres. Ils sont gratuits, ne demandent aucun compte, et rien au milieu ne cherche à vous vendre quoi que ce soit.
Le plus intéressant n’est pas ce qu’ils font. C’est l’endroit où ils le font.
Aucun de ces outils n’envoie quoi que ce soit nulle part. L’expression cron que vous collez, le JSON que vous êtes en train de déboguer, le bloc Base64 qui est peut-être un token : tout est traité par du JavaScript dans votre navigateur et rien n’en sort. Il n’y a pas de requête vers notre backend, parce que dans ce chemin il n’y a aucun backend.
Cela ressemble à une note technique. Ce n’en est pas une. Pensez à ce que les gens collent réellement dans les formateurs en ligne : des identifiants de base de données dans une config JSON, une clé d’API dans un payload de webhook, un JWT copié directement depuis les logs de production. Tout service qui traite cela côté serveur a ces données dans un journal de requêtes, qu’il l’ait voulu ou non.
Nous préférons ne pas les avoir. Manipuler les secrets des autres est une responsabilité dont nous ne tirons rien.
Les outils n’utilisent que ce que le navigateur embarque déjà : TextEncoder pour l’UTF-8, btoa pour Base64, JSON.parse, encodeURIComponent. Le parseur cron fait une centaine de lignes écrites à la main.
C’était aussi un choix délibéré. Un outil qui se présente comme “fonctionne en local” tout en tirant un script depuis le CDN de quelqu’un d’autre est local exactement dans la mesure où l’opérateur de ce CDN le décide. La dépendance ne disparaît pas parce qu’elle est pratique.
La seule exception, dite clairement : ces pages portent notre outil d’analytique, comme le reste du site. Il compte les pages vues. Il ne voit pas ce que vous tapez dans les outils, et le contenu de leurs champs n’est jamais transmis.
Réponse honnête : parce que les gens le cherchent. Celui qui écrit une ligne de crontab à deux heures du matin, en plissant les yeux sur */5 * * * * pour vérifier son calcul, est exactement la personne qui voudra savoir la semaine prochaine si ce job s’est vraiment exécuté.
Réponse moins cynique : nous regardons des expressions cron toute la journée. Le parseur montre ce que nous voudrions voir nous-mêmes, à savoir les cinq prochaines exécutions dans votre fuseau horaire, et non un paragraphe de prose qui vous récite votre propre planning. Quiconque s’est fait avoir une fois par la confusion entre UTC et heure locale sait pourquoi cela compte plus que la formulation.
Ils sont douze : parseur cron, Base64, formateur JSON, encodage d’URL, convertisseur de timestamp, générateur d’UUID et d’ULID, hachage SHA, testeur de regex, calculateur chmod, calculateur CIDR, générateur de mots de passe et une simple table de référence des codes de statut HTTP.
Cette dernière ne contient pas un gramme de JavaScript, et sa table a une colonne que les vingt autres du même genre sur internet n’ont pas : ce que chaque code signifie pour un moniteur. Un 401 signifie le plus souvent que votre contrôle a perdu ses identifiants, pas que le service est tombé. Un 429 signifie que le service est bien vivant et qu’il vous refuse, vous.
Et si un jour vous vous demandez si le cron que vous venez d’écrire s’est bien déclenché cette nuit, cette partie-là aussi, nous la faisons. Il faut simplement un compte.
Inscrivez-vous, récupérez une clé API, collez le curl dans votre cron. C'est tout.