Shell, Python ou Go : choisir le langage d'une automatisation

25 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 14 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Dans la formation « Développer pour les Ops », le langage est Python. Cette page, facultative, explique à qui vient du Bash pourquoi passer à Python quand un script grandit, et dans quel cas Go aurait sa place ailleurs. Le shell suffit tant que le script reste court, qu'il enchaîne des commandes et qu'il manipule peu de données. Au-delà, Python est le choix par défaut ; Go devient meilleur quand l'outil est distribué à de nombreuses machines sans interpréteur. Vous trouverez huit critères mesurables, un arbre de décision, puis leur application à certcheck.sh, le script hérité de la formation (un contrôle d'expiration de certificats lancé chaque nuit par cron, le planificateur de tâches de Linux).

Ce que vous allez apprendre

Citer le critère du Google Shell Style Guide et l'appliquer à un script.
Comparer shell, Python et Go selon huit critères mesurables.
Suivre l'arbre de décision pour justifier un choix par écrit.
Décider si certcheck.sh doit quitter le shell, et pour quel langage.
Savoir où apprendre la syntaxe du langage choisi.

Prérequis

Avoir écrit au moins un script Bash planifié, par exemple avec le guide des scripts Bash robustes.
Avoir compris pourquoi on automatise, notamment grâce à la leçon sur le toil et son élimination.

Aucune connaissance de Python ni de Go n'est requise : la leçon compare des propriétés, elle n'enseigne pas de syntaxe.

Quand faut-il quitter le shell ?

Le Google Shell Style Guide fixe une limite nette : le shell ne sert qu'aux petits utilitaires et aux scripts d'enrobage, et un script de plus de 100 lignes doit être réécrit dans un langage structuré. Le guide dit, à la lettre : « Shell should only be used for small utilities or simple wrapper scripts ». Il précise que le shell reste acceptable quand on appelle surtout d'autres programmes en manipulant peu de données, et qu'il faut utiliser autre chose dès que la performance compte.

Le même guide donne le seuil : « If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now ». Il ajoute que les scripts grandissent (« Bear in mind that scripts grow ») et qu'il vaut mieux réécrire tôt, avant que la réécriture coûte cher. Un langage structuré est un langage qui offre des types de données, des fonctions testables isolément, des modules et une gestion d'erreurs explicite, ce que le shell n'offre que partiellement.

Ce seuil de 100 lignes est un signal, pas une loi : un script de 150 lignes qui enchaîne des commandes en ligne droite peut rester en shell, et un script de 60 lignes qui construit du JSON à la main est déjà en difficulté. Le critère de fond est le flot de contrôle non trivial : boucles imbriquées, états partagés entre fonctions, cas d'erreur à distinguer.

Quels critères comparer avant de choisir ?

Huit critères permettent de trancher sans débat de goût : la taille et le flot, les données, les appels d'API, les tests, la distribution, la performance, l'équipe et l'outillage existant. Le tableau les résume ; les paragraphes suivants expliquent ceux qui ne se devinent pas. Lisez-le colonne par colonne : chaque langage a des cases où il est le meilleur.

Critère	Shell (Bash)	Python	Go
Taille et flot	Court, linéaire (moins de 100 lignes)	Moyen à grand, flot libre	Moyen à grand, flot libre
Données structurées (JSON, dictionnaires)	Faible : texte, `jq` en renfort	Natif (`json`, dictionnaires, listes)	Natif, typé (structures, `encoding/json`)
Appels d'API	Possible avec `curl`, erreurs à gérer à la main	Simple, avec la bibliothèque standard ou `requests`	Simple, bibliothèque standard
Tests	Possibles, peu naturels	Naturels (`pytest`)	Intégrés (`go test`)
Distribution	Un fichier, mais l'environnement doit fournir `bash` et les outils appelés	Un interpréteur et des dépendances à installer	Un binaire statique, sans interpréteur
Performance et concurrence	Faible, un processus par commande	Correcte, concurrence limitée	Excellente, concurrence native
Compétences de l'équipe	Acquises chez les admins	Courante, vite apprise	À acquérir, plus rare chez les ops
Outillage existant	Cron, CI, tout l'existant en shell	Bibliothèques pour presque tout	Écosystème cloud natif très riche

Pourquoi les données et les API font-elles basculer ?

Le shell ne connaît que du texte : tout JSON se manipule par jq ou par concaténation de chaînes, et c'est là que les scripts cassent. Un dictionnaire (une table qui associe une clé à une valeur) et une liste sont des types natifs en Python et en Go. Construire un corps JSON avec json.dumps échappe correctement guillemets et retours à la ligne ; le faire à la main dans une chaîne Bash ne les échappe pas. Pour un appel d'API, vous voulez aussi un délai maximal, la lecture du code HTTP, une reprise après échec : trois gestes qui deviennent des paramètres en Python ou en Go et des options de curl à assembler en Bash.

Pourquoi la distribution compte-t-elle autant ?

Un script se distribue en copiant un fichier, mais il ne s'exécute que si la machine cible fournit tout ce qu'il appelle. Bash est présent sur presque tous les serveurs Linux, mais pas dans l'image Alpine, qui fournit seulement ash de BusyBox (un script dont la première ligne, le shebang, est #!/usr/bin/env bash y échoue tant que bash n'est pas installé), et chaque outil appelé (openssl, jq, curl) doit y être aussi. Python demande un interpréteur (le programme qui lit et exécute le code) à la version attendue, et souvent des dépendances installées dans un environnement isolé. Go compile le code en un binaire statique, c'est-à-dire un exécutable unique qui embarque ce dont il a besoin et ne réclame ni interpréteur ni bibliothèque : on le copie, il tourne (avec CGO_ENABLED=0 pour les programmes qui utilisent le réseau, sinon Go peut lier la bibliothèque C du système). La compilation croisée (produire le binaire d'un autre système depuis le sien) se fait en fixant GOOS et GOARCH, comme le montre le guide Go sur le build et le versionnement.

Que valent les tests, la performance et l'équipe ?

Tester une automatisation suppose de pouvoir isoler la logique des effets de bord, ce que les fonctions typées de Python et de Go facilitent. Un test unitaire vérifie une fonction seule, sans réseau ni disque. En shell, il existe des outils de test comme bats-core (un cadre de test écrit pour Bash), mais la logique y est mêlée aux appels système, ce qui rend l'isolation pénible. Côté Python, pytest est le standard ; Go embarque go test, présenté dans le guide sur les tests en Go.

Pour la performance, un script shell lance un processus par commande : sur quelques milliers de lignes, c'est lent. La concurrence (traiter plusieurs choses en même temps) est native en Go avec les goroutines ; Python la propose avec asyncio ou des threads. Enfin, le meilleur langage est celui que votre équipe sait relire et maintenir : un outil en Go que personne ne sait corriger devient un risque. Le critère de l'outillage existant fonctionne de même : si vos pipelines, vos hooks et vos bibliothèques internes parlent déjà Python, partir sur Python coûte moins cher.

Comment trancher avec l'arbre de décision ?

L'arbre de décision ci-dessous ordonne les critères du plus éliminatoire au plus nuancé. Chaque question de forme losange a sa sortie « oui » sur la même ligne, à droite ; la sortie « non » descend. Lisez-le de haut en bas : la première question ramène au seuil du guide de style, la deuxième isole le cas où la distribution ou la performance justifient un langage compilé, la troisième vérifie que l'équipe sait maintenir ce choix.

Source · SVG

La branche par défaut mène à Python, volontairement. Python couvre le plus large éventail de besoins avec un coût d'entrée faible pour un admin qui connaît déjà Bash : structures de données natives, bibliothèque standard complète (fichiers, JSON, HTTP, arguments de ligne de commande) et tests naturels. Go ne passe devant que sur un besoin précis (distribution ou performance), et le shell reste le bon outil de la ligne de commande quotidienne. Une fois le langage choisi, notez la raison dans le README ou la description de la pull request : c'est elle qu'on relira quand quelqu'un proposera de tout réécrire.

Réécrire n'est pas systématique : un script stable, court et qui ne change plus n'a aucune raison de changer de langage. L'arbre s'applique à ce que vous écrivez ou modifiez en profondeur, pas à tout l'existant.

Que choisir pour certcheck.sh ?

certcheck.sh coche presque tous les critères de sortie du shell : 128 lignes, du JSON à construire, un appel d'API à une forge et un besoin de tests. Ce script, hérité de l'équipe d'exploitation, contrôle chaque nuit l'expiration des certificats d'un parc et ouvre un ticket sur la forge (le serveur Git de l'équipe, de type GitLab ou GitHub). Passons ses caractéristiques au crible, critère par critère.

Critère	Ce que montre `certcheck.sh`	Verdict
Taille et flot	128 lignes, six fonctions, compteurs partagés entre elles	Dépasse le seuil de 100 lignes
Données structurées	Le corps du ticket est un JSON assemblé dans une chaîne	À risque
Appels d'API	`POST` vers la forge avec `curl -s`, réponse jetée	Aucun délai, aucune lecture du code HTTP
Tests	Rien n'est testable sans cron, forge et vrais certificats	Pas de filet
Distribution	Un seul serveur d'administration	Sans enjeu

Le point le plus parlant est le corps du ticket. Voici la ligne d'origine, à éviter parce qu'elle fabrique du JSON par concaténation :

# ❌ JSON assemblé à la main : un guillemet dans $corps casse la requête
-d "{\"title\": \"Certificats a renouveler\", \"body\": \"${corps}\"}" \

Si un nom d'hôte ou un message contient un guillemet, le JSON devient invalide et la forge rejette la requête. Le script ne le verra même pas : le curl -s écarte la réponse et le script se termine toujours par exit 0, donc cron ne signale aucun échec. En Python, la même opération laisse la bibliothèque produire un JSON valide :

corps = json.dumps({"title": "Certificats à renouveler", "body": texte})

La sortie de cette ligne est toujours une chaîne JSON correcte, quel que soit le contenu de texte. Verdict : certcheck.sh bascule en Python. Le critère de taille et le besoin de tests suffisent déjà ; les données et l'API confirment. La version Python de référence du catalogue de labs n'importe que des modules de la bibliothèque standard (json, argparse, subprocess, urllib), donc il n'y a aucune dépendance à installer sur le serveur d'administration. Elle est plus longue que l'original, parce qu'elle gère aussi les options, la sortie JSON et les délais réseau : la longueur n'est pas le gain, la structure testable l'est.

Quand Go serait-il le meilleur choix pour certcheck ?

Go l'emporterait si certcheck devait être distribué à de nombreuses machines qui n'ont ni Python ni les bonnes dépendances. Imaginez que chaque serveur du parc exécute lui-même le contrôle de ses certificats : il faudrait installer et maintenir un interpréteur et ses paquets sur des centaines de machines, parfois de versions différentes. Un binaire statique issu de go build se copie, ne dépend d'aucun paquet système, et se compile pour l'architecture cible (GOARCH=arm64 pour des serveurs ARM) depuis un seul poste.

Deux autres signaux pousseraient vers Go : un très grand nombre de vérifications simultanées, où la concurrence native se rentabilise, et une équipe qui pratique déjà Go pour d'autres outils. Sans l'un de ces signaux, le coût d'apprendre et de maintenir un second langage ne se justifie pas. Pour un seul serveur d'administration qui lance un contrôle nocturne, Python reste le bon choix ; garder le contrat de l'outil indépendant du langage (mêmes options, mêmes codes de sortie) permet de réécrire en Go le jour venu sans toucher ceux qui l'utilisent.

Et PowerShell, Perl ou Ruby ?

Ces langages existent dans les parcs, mais cette formation ne les enseigne pas. PowerShell joue sur Windows le rôle que Bash joue sur Linux, avec les mêmes limites de taille ; Perl reste présent dans de vieux scripts à lire plutôt qu'à écrire ; Ruby est surtout connu pour Rails et pour Chef, dont les recettes s'écrivent en Ruby. Si votre équipe en maîtrise un, appliquez les mêmes huit critères : ils ne dépendent pas du langage.

Où apprendre la syntaxe du langage choisi ?

La formation enseigne la méthode, jamais la syntaxe : chaque langage a sa formation dédiée. Pour Bash, la formation Linux détaille les scripts, en particulier les scripts Bash robustes. Pour Python, la formation Python, les fondamentaux propose une piste « Automatisation » de dix-sept leçons qui couvre les premiers pas, les données, les fichiers, JSON, les API HTTP, la journalisation et les tests : c'est le chemin direct pour passer de Bash à Python. Si vous deviez un jour viser Go, la formation Golang part de zéro.

Pour la syntaxe de Python, la formation Python reste donc votre point de départ. Le module 1 de « Développer pour les Ops » en reprend seulement l'essentiel (leçons partagées), et les autres leçons ne la redisent pas : elles enseignent le métier du développeur sur un projet Python. Le verdict rendu pour certcheck.sh plus haut est leur fil d'entrée : certcheck bascule en Python, et la leçon qui clôt ce module, lire un code qu'on n'a pas écrit, s'ouvre sur le projet qui en résulte.

À retenir

Le Google Shell Style Guide limite le shell aux petits utilitaires et aux scripts d'enrobage ; au-delà de 100 lignes ou d'un flot non trivial, il faut réécrire dans un langage structuré.
Les scripts grandissent : réécrire tôt coûte moins cher que réécrire tard.
Huit critères tranchent : taille et flot, données, API, tests, distribution, performance, équipe, outillage existant.
Le shell ne connaît que du texte ; JSON et API sont la première cause de bascule vers Python ou Go.
Go gagne sur la distribution (binaire statique sans interpréteur) et la concurrence ; Python gagne sur la polyvalence et le coût d'entrée.
certcheck.sh (128 lignes, JSON, API, besoin de tests) bascule en Python, et ce verdict est le fil d'entrée de la formation ; Go ne se justifierait que pour une distribution à de nombreuses machines.
Un script court, stable et qui ne change plus n'a pas à être réécrit.
Écrivez la raison du choix de langage dans le README ou la pull request.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin