Tooling & Scripting
Définition
Je distingue volontairement scripting et tooling, qui sont souvent confondus mais répondent à des objectifs différents. Le scripting consiste à écrire un script pour répondre à un besoin ponctuel ou automatiser une tâche précise, le plus souvent pour un usage personnel et avec une logique d'efficacité immédiate. C'est un outil jetable ou semi-jetable, optimisé pour résoudre un problème, pas pour être réutilisé par d'autres.
Le tooling, à l'inverse, désigne un ensemble de scripts ou d'outils conçus de manière structurée, documentée et maintenable. L'objectif est de permettre leur utilisation par d'autres personnes, sans nécessiter une compréhension approfondie du code. Cela implique une réflexion sur l'ergonomie, la documentation, la modularité, et la capacité à être repris ou amélioré par d'autres utilisateurs.
Cette distinction est centrale dans ma manière de travailler. Quand je code en moins d'une heure pour résoudre un problème ponctuel, je fais du scripting. Quand je décide qu'un script mérite d'être conservé, documenté et publié, je bascule dans la logique tooling avec une exigence de qualité supérieure : README clair, gestion d'erreurs explicite, paramétrage propre.
Langages pratiqués
La compétence en pratique
Écrire un script de déploiement Bash idempotent pour ce portfolio
Pour mettre en place ce portfolio sur mon homelab, j'ai très vite eu besoin d'un processus de déploiement reproductible. Comme je rédige tous les contenus en dehors des pages actives, j'avais besoin d'un script qui transfère la nouvelle version au bon endroit, sauvegarde l'ancienne, applique les permissions correctement, et recharge Apache, sans risquer de casser le site exposé sur Internet.
J'ai donc écrit deploy.sh, un script Bash idempotent d'environ 90 lignes qui prend en entrée un zip de la nouvelle version. Le script vérifie les prérequis (root, présence du zip, présence d'unzip qu'il installe au besoin), sauvegarde automatiquement la version précédente dans un zip horodaté côté /tmp, déploie les fichiers dans /var/www/portfolio, applique les permissions Apache (www-data, 644 pour les fichiers, 755 pour les répertoires), et recharge Apache. Si Apache n'est pas actif, il est démarré. Le script utilise set -e en début pour échouer proprement au premier problème, et présente un résumé final avec le nombre de fichiers déployés et le chemin du backup.
L'écriture m'a pris un peu de temps à cause de plusieurs petites galères classiques en Bash : la détection correcte du dossier racine à l'intérieur du zip (qui n'a pas toujours le même nom que le zip), la gestion propre des permissions différenciées fichiers/dossiers avec find -exec, et le comportement du set -e avec les expressions composées qu'il faut savoir tempérer. Comme à chaque fois que j'écris un script, j'en ai profité pour apprendre quelque chose de nouveau, ici les bonnes pratiques de gestion d'erreur en Bash que je ne maîtrisais pas complètement.
Passer du scripting au tooling avec la sonde IDS conteneurisée
Mon projet personnel Docker-IDS-Sensor est l'exemple le plus complet de mon basculement dans une logique tooling. Là où un script de déploiement de sonde resterait personnel, j'ai construit un outil pensé pour être utilisé par d'autres : avec une documentation README structurée, une configuration paramétrable, et une logique modulaire qui permet de n'utiliser qu'une partie de la stack si on le souhaite.
Concrètement, le projet représente environ 500 lignes de Dockerfiles répartis sur quatre composants (Suricata, Zeek, Arkime, OpenCanary), chacun compilé depuis les sources Alpine pour avoir des versions récentes que les images publiques ne fournissent pas. À cela s'ajoutent les fichiers docker-compose qui orchestrent le tout, les scripts d'initialisation, et la documentation utilisateur.
Comme tous mes projets de tooling, le README est systématiquement présent et soigné. C'est pour moi non négociable : un outil publié sans documentation utilisable est un outil que personne n'utilisera, et qui ne servira donc à rien d'autre qu'à mon ego. Je documente l'installation, les prérequis, l'usage, les paramètres et les cas d'erreur courants.
Coder pour résoudre, et résoudre pour apprendre à coder
Une part importante de ma pratique du scripting vient de la résolution de challenges de sécurité. Je suis actif sur Root-Me où j'ai capitalisé un parcours conséquent, et j'utilise principalement Python pour ces challenges car il s'intègre naturellement avec les outils d'écosystème pentest et bénéficie de modules prêts à l'emploi (requests, pwntools, scapy, etc.).
Au fil des années, j'ai écrit un éventail varié de scripts dans ce cadre : scripts pwndbg pour automatiser des analyses de binaires en dynamique, brute-forceurs custom pour des contextes où les outils existants ne s'appliquaient pas, gestionnaires de mots de passe simples par curiosité de comprendre la cryptographie sous-jacente, exploits d'escalade de privilège, backdoors dans un cadre strictement éducatif, et même la création de challenges à mon tour pour d'autres apprenants.
Un exemple représentatif : sur un challenge web où il fallait extraire une information cachée derrière une logique d'authentification temporisée, j'ai écrit un script Python d'une vingtaine de lignes qui combinait requests et la mesure fine du temps de réponse pour faire un timing attack et déduire le contenu d'un secret caractère par caractère. Le challenge se résolvait théoriquement à la main, mais en quelques heures, là où le script l'a réglé en une minute trente.
Sur le bug bounty, je suis inscrit sur YesWeHack et Bugcrowd. Je n'ai pas encore décroché de récompense financière, mais j'ai trouvé plusieurs XSS côté client (DOM-based) sur des plateformes qui ne rémunéraient pas cette catégorie. C'est honnête à dire, et c'est une marche normale de progression dans cette discipline qui rappelle que la valeur d'une vulnérabilité ne dépend pas seulement de sa technicité.
Concevoir un outil pour la qualité des tickets DEV
Mon entreprise actuelle, Paritel, est culturellement réticente aux solutions "faites à la main" pour des sujets d'envergure : elle préfère investir dans des outils robustes plutôt que des bricolages personnels. C'est une position que je comprends et que je respecte, et qui change ma manière d'aborder le tooling en contexte professionnel.
Sur un besoin concret toutefois, je développe actuellement un outil d'aide à la création de tickets pour l'équipe DEV. Le constat est simple : les tickets reçus côté infrastructure manquent souvent de détails techniques essentiels (logs, contexte d'exécution, étapes de reproduction), ce qui rallonge inutilement les cycles de résolution. L'outil que je conçois vise à guider la création de tickets via un formulaire structuré qui force les champs manquants et propose des modèles selon le type d'incident remonté.
Mon niveau de maîtrise
Je considère aujourd'hui avoir un niveau intermédiaire en scripting et en tooling. Je ne suis pas développeur de formation et je n'évolue pas dans un contexte où le développement est une activité quotidienne. Mes compétences se sont construites principalement de manière autodidacte, en réponse à des besoins concrets liés à mes projets et à mon environnement technique.
Contextualisation : mes compétences sont opérationnelles sur les usages concrets que je rencontre : scripts d'automatisation système, parsing de données, scripts d'exploit en CTF, outils en ligne de commande, Dockerfiles. Elles restent limitées sur des sujets plus avancés de développement logiciel : architecture d'applications, design patterns objet, tests automatisés industrialisés, performance critique. Mon approche reste avant tout orientée vers l'efficacité opérationnelle plutôt que vers des logiques de développement complexes ou industrielles.
Place dans mon profil et vitesse d'acquisition
Le scripting occupe une place de multiplicateur d'efficacité dans mon profil. Je n'ai pas vocation à devenir développeur, mais sans scripting je serais largement moins efficace sur toutes mes autres compétences : configuration système automatisée, analyse de logs, exploitation de challenges sécurité, déploiements reproductibles. C'est une compétence dont je ne pourrais pas me passer même si elle n'est pas mon cœur de métier.
Vitesse d'acquisition : très progressive et continue. Chaque nouveau script est l'occasion d'apprendre quelque chose : une syntaxe spécifique, une bibliothèque, un pattern. Comme je m'impose de ne pas dépasser une heure sur un script ponctuel quand l'objectif est de gagner une dizaine d'heures à terme, la progression se fait en accumulant beaucoup de petites itérations plutôt qu'en de grandes phases d'apprentissage formalisées. Cette méthode me convient car elle reste motivante : chaque script résout un vrai problème immédiat.
Mon recul sur la compétence
Avec l'expérience que j'ai aujourd'hui, je conseille en premier lieu d'apprendre les bases de la programmation sérieusement avant de toucher au scripting système. Trop de gens commencent par copier-coller des scripts Bash depuis Stack Overflow sans comprendre ce qu'ils font, et finissent par bricoler des solutions fragiles. Comprendre ce qu'est une variable, un type, une condition, une boucle, une fonction, un retour d'erreur, c'est la base sur laquelle reposent tous les langages qu'on apprendra ensuite, du Bash au Python en passant par C ou Go.
Le second conseil, et c'est probablement le plus important sur la durée, est de rester curieux. Le scripting n'est pas un domaine qu'on maîtrise une fois pour toutes : les langages évoluent, les bibliothèques apparaissent et disparaissent, les paradigmes changent. La seule attitude qui fonctionne dans le temps, c'est de continuer à essayer des choses nouvelles, à lire le code des autres, et à se laisser embarquer par un projet personnel de temps en temps même quand il sort de notre zone de confort technique habituelle.
Enfin, je conseille de se fixer une limite de temps avant d'écrire un script. La règle que je m'applique est simple : si je passe plus d'une heure à écrire un script censé me faire gagner du temps, c'est que je suis en train d'apprendre quelque chose, pas d'automatiser. Les deux sont légitimes, mais il faut savoir lequel des deux on est en train de faire.
Évolution et formations
Mon objectif sur cette compétence est de continuer à progresser de manière organique via mes projets concrets, plutôt que par des certifications ou des cours formels. C'est cohérent avec la place que le scripting occupe dans mon profil : un multiplicateur d'efficacité, pas une spécialité.
Sur les langages que je veux explorer, ma priorité va vers Rust. Mon raisonnement est simple : Rust est aujourd'hui le candidat sérieux pour remplacer progressivement le C dans des contextes critiques (le noyau Linux intègre du code Rust depuis 2022, plusieurs projets système comme bottlerocket OS ou des composants Mozilla y sont écrits). Si Rust prend durablement la place du C dans les fondations de l'informatique, des OS seront un jour basés dessus, et il deviendra important de comprendre les différences de fonctionnement, notamment sur la gestion mémoire et la concurrence. Je préfère anticiper cette transition plutôt que la subir. Go reste une option pour des outils en ligne de commande performants, mais sans la même portée systémique.
Sur le plan des lectures techniques, je m'appuie notamment sur les ressources de la communauté VXunderground, qui publie des analyses approfondies d'exploits réels et de techniques offensives. Ce sont des lectures denses et exigeantes mais qui apprennent la vraie programmation système, pas la version filtrée des manuels académiques.
Sur les CTF et le bug bounty, je suis en pause active depuis quelques mois car la combinaison études + alternance ne me laisse pas suffisamment de temps. Dès la fin de mes études, je prévois de reformer une équipe CTF pour reprendre cette dynamique. Sur le bug bounty, mes comptes YesWeHack et Bugcrowd restent ouverts, et j'y reviendrai dès que j'aurai à nouveau du temps de cerveau disponible.
Concernant ma veille, elle suit la même structure que pour mes autres compétences : flux RSS, échanges sur Keybase avec ma communauté technique, et Twitter sur les comptes de chercheurs en sécurité offensive et mainteneurs d'outils.
Réalisations rattachées
Cette compétence est mobilisée dans deux réalisations détaillées. La Sonde IDS conteneurisée illustre le passage du scripting au tooling complet, avec environ 500 lignes de Dockerfiles, configuration paramétrable et documentation utilisateur. Le Portfolio auto-hébergé mobilise mon script Bash deploy.sh qui matérialise concrètement comment je conçois un outil de déploiement reproductible.