12 - Les outils du quotidien

Ce que tu vas apprendre

• Comment utiliser regex101.com pour debugger et partager tes regex
• Les commandes grep -E et grep -P pour chercher dans le terminal
• Comment sed remplace du texte avec des regex
• Le find/replace avec regex dans VS Code
• La différence entre les globs (.gitignore) et les vraies regex
• ESLint no-restricted-syntax pour interdire certains patterns

Prerequisites

• 11 - Patterns courants
• Etre a l'aise avec un terminal et un éditeur de code

Écrire une regex dans sa tête, c'est une chose. La tester sur de vraies donnees, la debugger quand elle ne matche pas ce qu'on attend, l'utiliser concrètement dans son workflow de dev... c'est une autre histoire. Je te presente les outils que j'utilise tous les jours et qui rendent les regex beaucoup moins penibles.

regex101.com : le laboratoire

Si tu ne retiens qu'un seul outil de cet article, c'est celui-la. regex101.com est un debugger en ligne qui te permet de tester une regex en temps réel.

Ce qui le rend indispensable :

• Explication en langage naturel : chaque partie de ta regex est décomposée dans un panneau a droite. Tu vois exactement ce que (?<=@)\w+\.\w+ signifie, token par token.
• Match highlighting : les correspondances sont surlignees dans ton texte de test. Tu vois immédiatement ce qui matche et ce qui ne matche pas.
• Choix du moteur : tu peux basculer entre PCRE2, JavaScript, Python, Go, Java... Les différences entre moteurs sont reelles et regex101 te les montre.
• Sauvegarde et partage : chaque regex recoit une URL unique. Quand un collegue te dit "ma regex ne marche pas", tu lui envoies un lien regex101 au lieu de jouer au telephone.

Pattern:  (\d{4})-(\d{2})-(\d{2})
Test:     Date: 2026-03-29
Matches:  2026-03-29 (group 1: 2026, group 2: 03, group 3: 29)

Mon conseil : bookmark regex101 et utilise-le systématiquement quand tu ecris une regex non triviale. Le temps que tu passes a taper le test string, tu le gagnes dix fois en debug.

grep : chercher dans le terminal

grep est probablement la commande que tu utilises le plus souvent avec des regex, meme sans t'en rendre compte. Deux flags sont essentiels.

grep -E (Extended regex)

Le flag -E active les regex etendues. Sans lui, tu dois echapper les parentheses, les accolades, le +... Un cauchemar.

bash# Sans -E : il faut echapper
grep '\(error\|warn\)' app.log

# Avec -E : syntaxe propre
grep -E '(error|warn)' app.log

Quelques combinaisons utiles :

bash# Trouver les lignes avec une adresse IP
grep -E '\b\d{1,3}(\.\d{1,3}){3}\b' access.log

# Trouver les TODO et FIXME dans le code
grep -rE '(TODO|FIXME):' src/

# Compter les occurrences
grep -cE 'status=[45]\d{2}' server.log

grep -P (Perl regex)

Le flag -P active le moteur PCRE, beaucoup plus puissant. Tu accedes aux lookahead, lookbehind, et aux classes Unicode.

bash# Lookahead : trouver "error" suivi d'un code numerique
grep -P 'error(?=\s+\d{3})' app.log

# Lookbehind : trouver le montant apres "prix:"
grep -P '(?<=prix:)\s*\d+' catalogue.txt

# Proprietes Unicode
grep -P '\p{L}+' multilingual.txt

Attention : -P n'est pas disponible partout. Sur macOS, grep utilise BSD grep qui ne supporte pas -P. Installe ggrep via Homebrew ou utilise ripgrep (rg), qui est plus rapide de toute facon.

sed : rechercher et remplacer

sed est l'outil de remplacement par excellence en ligne de commande. La syntaxe de base est s/ancien/nouveau/flags.

bash# Remplacer la premiere occurrence par ligne
sed 's/foo/bar/' fichier.txt

# Remplacer toutes les occurrences (flag g)
sed 's/foo/bar/g' fichier.txt

# Modifier le fichier en place (flag -i)
sed -i 's/console\.log/logger.info/g' src/app.ts

Avec des groupes de capture, sed devient vraiment puissant :

bash# Inverser nom et prenom
sed -E 's/^(\w+) (\w+)/\2 \1/' noms.txt

# Entourer les nombres de crochets
sed -E 's/([0-9]+)/[\1]/g' data.txt

# Transformer des dates US en dates FR
sed -E 's/([0-9]{2})\/([0-9]{2})\/([0-9]{4})/\3-\1-\2/g' dates.txt

Le flag -i modifie le fichier directement. Sur macOS, il faut écrire sed -i '' 's/...' (avec une chaîne vide). J'ai casse suffisamment de fichiers pour te recommander de toujours tester sans -i d'abord.

VS Code : find/replace avec regex

Dans VS Code, tu actives le mode regex en cliquant sur l'icone .* dans la barre de recherche (ou Alt+R). Ca change complètement la donne pour les refactorings.

Ce qui rend le find/replace de VS Code particulièrement utile, c'est le support des groupes de capture dans le remplacement avec $1, $2, etc.

Recherche:    const (\w+) = require\('(.+)'\);
Remplacement: import $1 from '$2';

Cette regex transforme tous tes require en import d'un coup. J'ai utilise ca pour migrer un projet de 200 fichiers en 5 minutes.

Quelques exemples pratiques :

# Renommer une prop React
Recherche:    isVisible={
Remplacement: isOpen={

# Ajouter un type a des parametres
Recherche:    function (\w+)\((\w+)\)
Remplacement: function $1($2: string)

# Convertir des string concatenations en template literals
Recherche:    "(.+)" \+ (\w+) \+ "(.+)"
Remplacement: `$1${$2}$3`

Le preview en temps réel est precieux : tu vois chaque remplacement avant de l'appliquer. N'hesite pas a utiliser "Replace All" quand tu es confiant, et "Replace" un par un quand le pattern est ambigu.

.gitignore : ce ne sont PAS des regex

Beaucoup de développeurs confondent les patterns de .gitignore avec des regex. Ce sont des globs, une syntaxe complètement différente.

Exemple concret :

gitignore# Globs - PAS des regex
node_modules/
*.log
dist/
!dist/keep-this.txt
build/**/*.map

La confusion la plus courante : écrire \.env dans .gitignore en pensant echapper le point. En glob, le point est litteral. Il suffit d'écrire .env.

Les globs sont aussi utilises dans les scripts npm, les fichiers tsconfig.json (include/exclude), et les configurations de bundlers. Retiens juste : si c'est un fichier de config qui filtre des chemins, c'est probablement du glob, pas de la regex.

ESLint no-restricted-syntax

ESLint propose une regle no-restricted-syntax qui utilise des sélecteurs AST, pas directement des regex. Mais tu peux combiner ca avec des regex dans d'autres regles pour interdire certains patterns dans ton code.

json{
  "rules": {
    "no-restricted-syntax": [
      "error",
      {
        "selector": "CallExpression[callee.name='eval']",
        "message": "eval() est interdit. Utilise une alternative securisee."
      },
      {
        "selector": "CallExpression[callee.property.name='forEach']",
        "message": "Prefere for...of a .forEach() pour la lisibilite."
      }
    ],
    "no-restricted-imports": [
      "error",
      {
        "patterns": ["../../../*"]
      }
    ]
  }
}

Et avec @typescript-eslint/naming-convention, tu peux utiliser des regex pour imposer des conventions de nommage :

json{
  "@typescript-eslint/naming-convention": [
    "error",
    {
      "selector": "interface",
      "format": ["PascalCase"],
      "custom": {
        "regex": "^I[A-Z]",
        "match": false
      }
    }
  ]
}

Cette regle interdit le prefixe I sur les interfaces (comme IUser). Une convention qui vient de C# et qui n'a pas sa place en TypeScript, a mon avis.

Tu retrouves un article sur les bonnes pratiques de configuration ESLint sur paltemps.fr.

Résumé

• regex101.com est ton meilleur ami pour debugger, comprendre et partager des regex
• grep -E pour les regex etendues, grep -P pour le moteur Perl (lookahead, Unicode)
• sed pour le search/replace en ligne de commande, avec -i pour modifier en place
• VS Code supporte les regex dans le find/replace avec $1, $2 pour les groupes de capture
• Les patterns de .gitignore sont des globs, pas des regex
• ESLint permet d'interdire des patterns de code avec des sélecteurs AST et des regex

Article précédent : 11 - Patterns courants Article suivant : 13 - Unicode et regex

Sources

• regex101.com - Online regex tester
• GNU grep manual - Regular Expressions
• ESLint no-restricted-syntax