Tout administrateur système a croisé un jour, au détour d'un serveur, un script_final_old_v3_OK_last.py sans logs, sans historique, avec un mot de passe en clair à la ligne 42 et un commentaire # TODO: gérer les erreurs daté de 2014.
Après cinq ans de développement en parallèle de mes activités professionnelles, je publie Scrippy, un framework Python sous licence MIT pour écrire des scripts d'exploitation standardisés, robustes et prêts pour la production.
Sommaire
Le constat : le script d'exploitation, ce grand oublié
Dans beaucoup d'équipes, les scripts d'exploitation sont écrits vite, chacun à sa manière, puis maintenus dans la douleur. Le cycle de vie typique est bien connu :
- « C'est juste un petit script, je l'écris vite fait. »
- Le petit script part en production.
- L'auteur part en vacances (ou change d'entreprise).
- Le script plante un dimanche à 3 h du matin.
- L'astreinte découvre qu'il n'y a ni logs, ni historique, ni documentation, et que la configuration est codée en dur entre deux
print("ici").
Le tout agrémenté d'un mot de passe qui s'affiche fièrement dans la sortie standard. Oui, hunter2, on te voit.
Le principe : un en-tête déclaratif
Avec Scrippy, un script décrit son comportement dans un en-tête déclaratif : auteur, version, description, configuration attendue, options acceptées, utilisateurs autorisés, nombre d'exécutions simultanées. Une seule instruction with dans le code suffit ensuite pour bénéficier de l'ensemble des fonctionnalités, sans écrire une seule ligne de plomberie :
- un fichier de log par exécution, avec sortie colorée sur le terminal ;
- un historique complet des exécutions (paramètres, durée, code retour) ;
- un fichier de configuration par script, chargé et validé au démarrage ;
- des options de ligne de commande analysées et validées depuis l'en-tête, avec un
--helpgénéré automatiquement (personne n'aura plus d'excuse pour ne pas RTFM) ; - le masquage automatique des secrets dans les logs et l'historique ;
- la restriction des utilisateurs et groupes autorisés à lancer le script ;
- une limite d'exécutions simultanées, avec file d'attente ;
- un répertoire de travail temporaire par exécution, supprimé automatiquement ;
- une gestion d'erreurs propre et des codes retour exploitables par votre ordonnanceur préféré.
Un exemple vaut mieux qu'un long discours
Voici un script de surveillance de l'occupation d'un système de fichiers. Toute ressemblance de l'auteur avec un personnage des Monty Python n'est évidemment pas fortuite : on fait du Python, on a des traditions.
#!/usr/bin/env python3
"""
--------------------------------------------------------------------------------
@author : Luiggi Vercotti
@date : 2026-10-08
@version : 1.0.0
@description : Monitor filesystem usage
--------------------------------------------------------------------------------
Configuration:
@conf:thresholds|warning|int|false
--------------------------------------------------------------------------------
Options:
@args:mount-point|str|Mount point to check|1|/|||false|false
--------------------------------------------------------------------------------
"""
import shutil
import scrippy_core
from scrippy_core import logger
def main():
with scrippy_core.ScriptContext() as _context:
usage = shutil.disk_usage(_context.args.mount_point)
percent = round(usage.used * 100 / usage.total, 1)
if percent >= _context.config.get("thresholds", "warning", "int"):
logger.warning(f"[+] {_context.args.mount_point}: {percent}% used")
if __name__ == '__main__':
main()Ce court script dispose déjà de --help, --version, d'un fichier de configuration validé, d'une option --mount-point validée, d'un log par exécution (--log), d'un historique (--hist), d'un mode debug (--debug) et d'un espace de travail temporaire. Le tout sans avoir vendu son âme à un fichier YAML de 800 lignes, ni avoir à relire une n-ième fois la doc de argparse, ni sans incantation mystique pour la configuration de log, ni pentacle renversé. Ni !
Le double bénéfice
D'une part, tous les scripts d'exploitation suivent le même standard : ils se lisent, s'exploitent et se maintiennent de la même façon, quel que soit leur auteur. Le script du collègue parti n'est plus une boîte noire.
D'autre part, ils s'écrivent beaucoup plus vite : inutile de recoder ces contrôles dans chaque script, on se concentre sur ce qu'il doit réellement faire. Le temps gagné peut être réinvesti dans des activités à haute valeur ajoutée, comme le troll sur systemd.
Les modules
Le cœur (scrippy-core) est complété par des modules optionnels :
-
scrippy-remote: exécution distante et transferts de fichiers (SSH/SFTP, FTP/FTPS, CIFS) ; -
scrippy-api: client d'API REST, avec prise en charge d'OpenAPI ; -
scrippy-db: requêtes PostgreSQL, MySQL et SQLite ; -
scrippy-mail: envoi et lecture de courriels (SMTP, IMAP, POP3) ; -
scrippy-snmp: opérations SNMPget,walketset; -
scrippy-git: gestion de dépôts Git ; -
scrippy-template: génération de documents à partir de modèles Jinja2.
Pas un prototype
Scrippy n'est pas né d'un week-end pluvieux. Il tourne depuis plusieurs années en production, sur des usages bien réels. Il a donc survécu à des mises à jour, des migrations et des vendredis après-midi, ce qui constitue une forme de certification assez exigeante.
Pourquoi seulement maintenant ?
Parce que je n'étais pas satisfait de la documentation. Un outil mal documenté ou dont la documentation n'est pas à jour est un outil qu'on n'adopte pas, et, même si jusque là celà a été le cas pour Scrippy, « Use The Source, Luke » n'est pas une stratégie d'adoption. Je ne voulais pas publier un projet que d'autres ne pourraient pas s'approprier.
Dans les faits le code a toujours été publié mais n'ayant jamais fait aucune annonce l'adoption de Scrippy est relativement comparable à celle de GNU Hurd !
La question qui fâche : et l'IA dans tout ça ?
Avant que le Jihad butlérien ne se lève dans les commentaires, par souci de transparence : le code de Scrippy a été écrit par un humain, sur cinq ans.
Claude m'a aidé à remettre à plat la documentation, à l'enrichir d'un tutoriel progressif (voir la documentation pas à pas) et à maintenir à jour les README.md des dépôts. Il m'a également permis de détecter et corriger quelques bogues passés sous les radars malgré des années d'exploitation, ce qui est à la fois utile et clairement vexant.
L'IA reste un outil. Le meilleur des outils, entre les mains de quelqu'un qui ne sait pas ce qu'il fait, ne le rendra pas meilleur : un rm -rf reste un rm -rf, quelle que soit la qualité du clavier. C'est l'expérience, la compréhension du besoin et l'exigence qui font la qualité d'un projet. L'outil permet d'aller plus loin et plus vite.
Licence
Scrippy est un logiciel libre distribué sous licence MIT : vous pouvez l'utiliser, le modifier, le redistribuer et l'intégrer à vos projets, y compris commerciaux, à la seule condition de conserver la mention de copyright et le texte de la licence.
Vos retours sont les bienvenus
Si vous écrivez des scripts d'exploitation en Python, je serais ravi d'avoir vos retours, critiques comprises : la syntaxe de l'en-tête, les fonctionnalités manquantes, ou la comparaison avec ce que vous utilisez aujourd'hui.
Les rapports de bogues sont acceptés. Les trolls aussi, tant qu'ils sont de qualité (et vous pouvez y aller car mon Prumpleffer a été calibré par tTh).
Aller plus loin
- Le site officiel (149 clics)
- La documentation pas à pas (47 clics)
- Le code source (87 clics)
# Pourquoi
Posté par Pouetpouet . Évalué à 1 (+2/-1).
J'imagine que ça doit encore se faire, j'ai vécu ça aussi… mais créer un outils dédier pour gérer une mauvaise pratique me semble pas la bonne solution. Gérer sa production avec un outils de config management et le tout tracké dans un CVS c'est quand même la base d'une équipe un peu sérieuse
[^] # Re: Pourquoi
Posté par Doug Le Tough (site web personnel) . Évalué à 7 (+6/-0).
Il est évidemment recommandé que ces scripts soient centralisés, versionnés et déployés de manière automatisée. L'un n'empêche pas l'autre, pas plus qu'un CVS et un outil de gestion de configuration n'empêchent
script_final_old_v3_OK_last.pyd'être déployé en prod (déjà vu).L'idée est d'apporter plusieurs choses et pour lister les princpales:
Un cadre aux scripts d'exploitation, de manière à gagner en temps de développement et de maintenance (gestion déclarative des paramètres de configuration, des options, configuration du logger, etc.). Cette étape représente généralement la plus grande partie du développement d'un script d'exploitation, alors que c'est peu ou prou toujours la même chose (i.e. valider la configuration du script, jouer avec les arcanes d'argparse pour gérer les options, configurer un logger, gérer les informations sensibles dans les sorties).
Un historique d'exécution des scripts qui indique l'heure de début, l'heure de fin, la durée d'exécution, l'utilisateur qui a exécuté le script, si le script a été exécuté via sudo (et, le cas échéant, qui a exécuté le sudo), le code retour du script, et, si le script s'est terminé sur une erreur, quelle a été cette erreur, etc. Et je parle d'un historique configurable : par défaut, tu peux consulter les 50 dernières exécutions, mais tu peux décider de conserver les 200 dernières. Le genre de truc qui permet de vérifier rapidement pourquoi le script
mon_script.pya planté il y a 15 jours sans que personne ne s'en aperçoive.Des logs standardisés, la possibilité de gérer les exécutions parallèles, d'éviter la fuite d'informations sensibles dans les logs, etc., mais également de consulter les logs des dernières exécutions. Parce que lorsque le script critique, exécuté par un ordonnanceur toutes les 5 minutes, a planté un dimanche à 3 heures du matin, tu veux savoir pourquoi, même s'il t'a fallu 30 minutes pour te réveiller. Et dans ces moments-là, tu ne veux pas avoir à réfléchir (où est le log ? Comment y accéder ? Comment identifier le bon log parmi les gazillions de logs conservés ?). Avec Scrippy, c'est simplement
mon_script.py --histpour visualiser l'historique d'exécution et identifier l'exécution qui a planté, puismon_script.py --log <SESSION_ID>pour visualiser le log qui contient la raison du plantage.Bien d'autres choses choses que je vous laisse découvrir grâce au tutoriel :-)
Évidemment, Scrippy n'est pas magique. Comme indiqué dans la dépêche à propos de l'IA, le meilleur outil donné à un mauvais ouvrier n'en fera pas un bon ouvrier.
[^] # Re: Pourquoi
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Les bonnes pratiques ne sont pas plus facultatives, mais il n'empêche que si tu avais déjà travaillé dans une boîte (les très grosses ont souvent leur version de scrippy), tu saurais que faire des scripts à l'arrache, c'est la norme d'un informaticien. Alors pouvoir centraliser facilement les processus et les confirmations, c'est pas mal du tout.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Tu n'as pas compris
Posté par cg . Évalué à 10 (+9/-0).
Le système du type
script_final_old_v3_OK_last.pyest le pinacle du développement ! C'est l'intégration parfaite entre le code, le fichier qui contient le code, et le système de versionnage qui contient le code. Le tout dans un artefact unique !J'en veux pour preuve l'implémentation de référence pour le suivi de version : finalfinal.
[^] # Re: Tu n'as pas compris
Posté par Doug Le Tough (site web personnel) . Évalué à 2 (+1/-0).
Merci pour ce partage, je ne connaissais pas FinalFinal, j'ai bien ri et maintenant je doute :-D
[^] # Re: Tu n'as pas compris
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 10 octobre 2026 à 11:03.
Blague à part, personnellement je trouve ton travail très intéressant mais je n'ai jamais rencontré le script dont tu te moques à plusieurs reprises. Pas certain que prêter des mauvaises intentions/pratiques aux autres soit ton meilleur argument.
(Le sarcasme et l'autodérision sont bienvenus mais l'insistance nuit au message, je pense.)
Adhérer à l'April, ça vous tente ?
[^] # Re: Tu n'as pas compris
Posté par Doug Le Tough (site web personnel) . Évalué à 2 (+1/-0).
Merci :-)
Tant mieux !
script_final_old_v3_OK_last.pyest un nom caricatural mais assez représentatif d'un script d'exploitation développé rapidement pour répondre à un besoin ponctuel qui a été maintenu par de multiples personnes directement sur la prod.C'est donc surtout une manière de présenter Scrippy car dans les faits rien n'empêche un script qui utilise Scrippy d'avoir un tel nom !
Si vous, car j'ai l'impression que vous êtes plusieurs, n'avez jamais rencontrés ce genre de script, soyez en heureux mais sachez qu'on les trouve dans bon nombre d'entreprises et administrations, qu'ils sont souvent en charge de processus critiques et que leur nom est le moindre de leur défaut.
[^] # Re: Tu n'as pas compris
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
Oui, dommage que tes collègues n'aient pas eu vent de cpold.
Adhérer à l'April, ça vous tente ?
[^] # Re: Tu n'as pas compris
Posté par Luc-Skywalker . Évalué à 5 (+3/-0).
dans le BTP, je rencontre ça de temps en temps, pas sur des scripts, mais sur des fichiers. Qu'on va nommer genre: "nom_operation bilan à diffuser v2 OK+éventuellement la date.pdf" accompagné de "nom_operation bilan courant v3-travail+éventuellement la date.xslx"
C'est un bel et utile effort: on peut filtrer par nom d'opération + éventuellement par date, vive l'informatique ;)
C'est le lot assez courant des petites structures, qui interviennent sur de petits projets. Je m'y suis fait.
Les grosses majors (Maitres d'Ouvrages, Maitres d'Oeuvre, Entreprises, fournisseurs de logiciel ou de produits matériels etc) sont quand à elles passées depuis très longtemps à la vitesse supérieure (y compris avec l'aide du cloud et de l'IA), mais c'est une autre histoire !
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Tu n'as pas compris
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0).
c'est écrit « éventuellement la date » avec les espaces dans le nom du fichier ?
ou est-ce la date au format ISO 8601 largement sous-utilisé de mon expérience ? (bon, on supposera AAAAMMJJ éventuellement suffixé de _2, _3 pour les modifs du même jour :D o_O mais pas le même _2 ou _3 que le collègue, faut pas déconner, comme s'il fallait se coordonner…). Quand ce n'est pas indiqué dans les propriétés du document de travail — que personne ne pense à regarder — dont certaines qui se retrouveront à l'insu de notre plein gré dans le PDF généré qui pète par ailleurs allègrement certaines mises en forme bichonnées avec amour et expertise /o\)
[^] # Re: Tu n'as pas compris
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
non évidemment, c'est parce que eventuellementladate c'était tout souligné en rouge :)
Sinon c'est AAAAMMDD, AAMMDD, AA-MM-DD … mais comme dit: c'est pas toujours le cas.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Tu n'as pas compris
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 13 octobre 2026 à 22:31.
Moi, si, j'ai souvent vu.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Tu n'as pas compris
Posté par vpo . Évalué à 3 (+2/-0).
Surpris, le premier commit de FinalFinal et les suivants n'ont pas été effectués durant des 1e avril.
# docopt
Posté par steph1978 . Évalué à 7 (+5/-0).
J'utilise baker qui permet, à partir de fonction annotées, de construire la doc et faire le dispatch. Il y a pas mal de bibliothèques qui permettent cette approche. J'ai aussi utilisé mando.
J'utilise docopt, qui propose, à l'inverse, de construire le "boilerplate" à partir de la doc. Une démarche saine.
Mais scrippy a l'air encore plus complet. Je testerai pour ma prochaine CLI.
[^] # Re: docopt
Posté par Doug Le Tough (site web personnel) . Évalué à 4 (+3/-0).
Très intéressant, je ne connaissais pas et ça répond en partie au même besoin que
Scrippy.bakerpar contre à l'air de répondre à un besoin bien différent.N'hésite pas à revenir avec des questions si besoin, voire présenter ce que tu as fais avec.
# Pas un prototype ?
Posté par Colin Pitrat (site web personnel) . Évalué à 5 (+4/-1).
Ah ben oui mais tout cela est vrai pour
script_final_old_v3_OK_last.pyqui tourne depuis plus de 10 ans en prod mon cochon! Alors ton truc kikoolol en couleur de djeuns tu peux te le garder, ça ne marche même pas avec perl (que tout vrai sysadmin préfère à python)![^] # Re: Pas un prototype ?
Posté par Doug Le Tough (site web personnel) . Évalué à 5 (+4/-0).
Que tout vrai sysadmin à la retraite depuis 15 ans, préfère à Python :-p
[^] # Re: Pas un prototype ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Mais le constat que tu fais est justement l’œuvre de pythonistes ! Je croise encore des perl et bizarrement c’est toujours écrit avec un souci de maintenabilité même quand tu apprends après que c’est fait à l’arrache.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas un prototype ?
Posté par Doug Le Tough (site web personnel) . Évalué à 2 (+1/-0).
Dans ma carrière j'ai pu rencontrer le pire comme le meilleur dans chacun des langages, du shell au C, en passant par Pyhton, Perl et Ruby et d'autres encore.
Malheureusement je ne crois pas que ce soit lié au langage en lui même.
Ce n'est même pas toujours lié à la personne ou à l'équipe et pour ma part je pense que c'est lié au cadre qu'on donne aux personnes en charge du code.
D'où Scrippy, qui n'est un cadre qui facilite pas mal d'aspect de la création, l'exploitation et la maintenance d'un script Python.
# je vais essayer
Posté par cdg . Évalué à 1 (+1/-0).
Ca m a l air d etre une bonne idee. Je vais l essayer
pour info, nous avons ici un dept IT mais nous avons nos propres serveurs (non gere par IT) qui servent pour tester nos builds. Jusqu a maintenant j utilisait des scripts python pour lancer les diffents jeux de tests et archiver ca en DB
[^] # Re: je vais essayer
Posté par Doug Le Tough (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 20 octobre 2026 à 22:14.
Voilà de très bons cas d'utilisation pour Scrippy !
N'hésite pas à faire un retour ou poser des questions.
Pour plus de réactivité, tu peux me contacter via IRC (libera.chat / #tetalab)
# mise
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
J'utilise mise pour ce genre d'usages. Il n'est pas équivalent mais il permet aussi de gérer des variables d'environnement (comme direnv) et de gérer les outils
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mise
Posté par Benoit Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Aussi utilisateur de mise, pour faciliter l'(ré)installation d'un environnement de travail pour un projet donné, pour un nouveau dans l'équipe ou un changement d'ordinateur, mais aussi comme doc de cet envoronnement, pour la capacité de mise à jour via renovate, pour la gestion de la chaîne d'approvisionnement logicielle, etc.
[^] # Re: mise
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Oui pour moi il va plus loin. À la base j’utilisais just que j’avais découvert quand il a eu son petit buzz. Au boulot les gens utilisent plutôt task. Mais je préfère amplement mise qui est bien plus ambitieux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.