Table des matières :
- Ce que couvre exactement la recherche de code GitHub (et ce qu’elle ne couvrira jamais)
- Syntaxe de requête : opérateurs, expressions exactes, regex et pièges classiques
- Les qualificateurs qui font gagner 80% du temps : repo/org, language, path, filename, symbol
- Scénarios concrets côté PrestaShop : hooks, overrides, Symfony, SQL et dette technique
- Recherches enregistrées : industrialiser la veille (maintenance, sécurité, migration) sans réinventer des runbooks
- Automatiser la recherche : API GitHub, quotas, et usage réaliste dans une CI
- Jeux de requêtes prêts à l’emploi (à transformer en recherches enregistrées)
Ce que couvre exactement la recherche de code GitHub (et ce qu’elle ne couvrira jamais)
La recherche de code GitHub n’est pas un grep global sur l’intégralité de l’historique Git. C’est une recherche sur un index construit par GitHub à partir du contenu des dépôts (publics et/ou privés selon vos droits). Dit autrement : vous interrogez une base dérivée, pas votre repo « live ». Ça explique deux comportements fréquents en audit :
- des résultats qui arrivent avec un léger décalage après un push (temps d’indexation) ;
- des fichiers qui n’apparaissent jamais (binaires, contenus non indexés, limites de taille, contenus générés, etc.).
La documentation GitHub décrit clairement l’approche : on combine des mots-clés, des qualificateurs et des opérateurs pour réduire le bruit et viser un contexte précis (GitHub Docs — Searching code). Pour une équipe PrestaShop (8.1/9.x, PHP 8.1–8.3 selon votre stack), l’index GitHub doit être vu comme un outil de navigation et d’enquête :
- excellent pour cartographier un codebase (où est défini ce service ? où ce hook est-il utilisé ?),
- utile pour préparer un audit (surface d’attaque, dette technique),
- insuffisant comme source de vérité pour des contrôles de conformité stricts (par exemple « 0 occurrence dans toutes les branches ») ou des analyses sémantiques.
Pour ça, vous aurez toujours besoin d’un check local/exécutable : ripgrep pour du balayage rapide, semgrep pour des règles, phpstan/psalm pour du typage et des invariants, et des tests dans votre CI.
Enfin, gardez en tête les contraintes « produit » : pagination, limites de résultats, quotas sur l’API, et un modèle de pertinence qui n’est pas optimisé pour vos conventions internes (naming de services Symfony, classes Legacy PrestaShop, architecture de modules, etc.). Quand vous cherchez une régression (ex. hook non déclenché, override qui masque une classe, fuite de token dans un workflow), vous devez forcer le contexte via des qualificateurs (repo:, path:, language:…), sinon vous perdez du temps à trier du bruit.
Syntaxe de requête : opérateurs, expressions exactes, regex et pièges classiques
La recherche GitHub est pilotée par une syntaxe compacte : mots-clés, guillemets, opérateurs booléens et qualificateurs. Les règles de base (dont la priorité des opérateurs) sont récapitulées dans la doc (GitHub Docs — Understanding the search syntax).
Pour du code, la différence entre hookAction (terme) et "hookAction" (expression exacte) est critique : sans guillemets, GitHub peut découper/pondérer et vous remonter des fichiers « proches » mais inutiles. En pratique, sur des dépôts PrestaShop, les guillemets font gagner du temps sur :
- les appels de méthodes (
"Hook::exec"), - les identifiants exacts (
"actionProductSave"), - les clés de configuration (
"PS_SSL_ENABLED"), - les noms de services (
"prestashop.adapter.legacy.context"…).
Les opérateurs booléens AND, OR, NOT (ou -terme pour exclure) sont particulièrement efficaces combinés à la localisation (path:) :
("Hook::exec" OR "dispatchWithParameters") AND repo:PrestaShop/PrestaShop -path:tests/
Ce type de requête sert très bien à comparer les usages Legacy (Hook::exec) et des appels plus récents. Vous pouvez aussi vous en servir pour détecter « ce qui manque » dans une arborescence attendue (ex. une migration Symfony où les services ne sont pas déclarés là où votre convention l’impose) :
"services.yml" AND repo:votre-org/votre-module NOT path:config/
Pièges classiques (et comment les éviter)
- Oublier le périmètre (
repo:/org:) : vous faites une recherche « Internet », pas une recherche de prod. - Ne pas exclure
vendor/etnode_modules/: les dépendances prennent le dessus sur votre code. - Chercher trop large puis scroller : mieux vaut ajouter un
path:ou unlanguage:que « trier à la main ». - Confondre “je veux toutes les branches” et “je veux le code actif” : selon votre contexte, il faudra compléter GitHub Search par des recherches locales (ou cibler une référence/branche si votre expérience GitHub le permet).
Les regex et la recherche « structurelle » font gagner du temps aux équipes qui maintiennent plusieurs modules : elles évitent de multiplier les requêtes par variante (snake_case, camelCase, suffixes). GitHub Docs — Searching code documente explicitement le support des regex en recherche de code. Exemple concret pour détecter des accès directs à $_GET/$_POST dans un module (souvent symptomatique d’un contournement de Tools::getValue() et d’un risque de validation insuffisante) :
/\$_(GET|POST)\b/ repo:votre-org/votre-module language:PHP
Astuce pragmatique : si votre objectif est “réduire le risque”, utilisez la regex pour faire émerger une liste de fichiers à relire, puis basculez sur une revue ciblée (validation, encodage, token CSRF, échappement Smarty/Twig).
Les qualificateurs qui font gagner 80% du temps : repo/org, language, path, filename, symbol
Le mot-clé « recherche de code GitHub » est souvent compris comme une simple barre de recherche. En pratique, les qualificateurs sont le vrai levier : ils servent à restreindre le périmètre et à transformer une requête vague en requête exploitable (GitHub Docs — Searching code). Sans repo: (ou org:), vous ne cherchez pas votre code de production.
Les qualificateurs les plus utiles en environnement e-commerce (Symfony + Legacy PrestaShop, templates Smarty/Twig, YAML, SQL) :
repo:owner/name/org:nom/user:nom: délimite le périmètre (indispensable si vous avez des forks, des POCs, des miroirs).language:PHP,language:JavaScript,language:Smarty,language:Twig,language:YAML: réduit drastiquement le bruit.path:/-path:: exclutvendor/,node_modules/,var/cache/,tests/,translations/.filename:/extension:: cibleservices.yml,composer.json,.github/workflows/*, etc.
Pour rendre ça actionnable en équipe (et pas uniquement « des trucs à connaître »), voici un mini-tableau de patterns qui marchent bien dans des dépôts PrestaShop :
| Objectif | Requête type | Pourquoi ça marche |
|---|---|---|
| Ignorer les dépendances | org:votre-org -path:vendor/ -path:node_modules/ |
Vous regardez votre code, pas celui des vendors |
| Cibler la config Symfony | filename:services.yml org:votre-org |
Localise rapidement les points d’injection |
| Traquer du debug oublié | ("var_dump" OR "die(" OR "dd(") org:votre-org -path:vendor/ |
Prévient des mises en prod « sales » |
| Explorer templates | extension:tpl org:votre-org / extension:twig org:votre-org |
Utile pour XSS/échappement et perf front |
Troisième brique : la recherche « code-aware » via symbol: (quand disponible dans votre expérience GitHub). Elle sert à retrouver un symbole (classe, fonction, méthode) même si le code bouge autour. Pour une base PrestaShop avec surcouche Symfony, c’est précieux : vous passez d’un nom de classe à ses définitions/références sans dépendre d’un simple Ctrl+F dans un fichier. Exemple :
symbol:hookActionProductSave repo:PrestaShop/PrestaShop
Limite à connaître : language: ne reflète pas votre réalité d’exécution PHP (8.1 vs 8.2) ni votre autoload effectif ; c’est une détection par GitHub. Sur des dépôts où Smarty/Twig sont dans des .tpl / .twig, pensez à mixer path: et extension: plutôt que de compter uniquement sur language:.
Scénarios concrets côté PrestaShop : hooks, overrides, Symfony, SQL et dette technique
Premier cas d’usage (souvent le plus rentable) : cartographier les hooks et repérer les points d’extension « réels » vs « théoriques ». Le cœur PrestaShop contient des hooks dynamiques et des patterns d’appel qui rendent la découverte pénible à la main. Une requête GitHub bien cadrée vous donne une base exploitable avant d’écrire un module. En complément, l’article interne sur les hooks dynamiques aide à comprendre pourquoi une simple recherche par nom ne suffit pas : Hooks PrestaShop : rechercher et identifier les hooks dynamiques.
Exemples de requêtes efficaces pour auditer un module existant qui « n’accroche pas » (scénario classique : une boutique française multi-boutiques, plusieurs modules « marketing », et un hook attendu qui ne déclenche rien en prod) :
"registerHook" repo:votre-org/votre-module language:PHP
"Hook::exec" repo:votre-org/votre-module language:PHP
"actionProductSave" repo:votre-org/votre-module
Deuxième cas d’usage : retrouver rapidement les overrides et les contournements Legacy. PrestaShop traîne encore des zones où l’override est le chemin de moindre résistance, mais c’est aussi une source classique d’effets de bord (priorité de chargement, collisions entre modules, régressions à la mise à jour). Une requête du type :
path:override/ repo:votre-org/votre-boutique language:PHP
… vous donne une vision immédiate de la surface de risque avant une montée de version (8.1 → 9.x). À ce stade, vous avez intérêt à croiser avec une démarche de migration et rollback côté projet : Migration PrestaShop 9 : sécurité, tests et plan de rollback.
Troisième cas d’usage : chasse à la dette technique et aux points chauds perf/sécu. Pour une boutique à fort trafic (pics soldes, campagnes TV, marketplaces), vous cherchez typiquement : requêtes SQL non paramétrées, accès directs à la DB, usages d’anciennes APIs, appels réseau synchrones dans des hooks critiques (panier, paiement, checkout). Exemple de pré-filtre pour repérer du SQL « construit à la main » :
("SELECT " OR "INSERT " OR "UPDATE ") AND ("." OR "_DB_PREFIX_") repo:votre-org/votre-module language:PHP -path:vendor/
Ce n’est pas un audit sécurité à lui seul, mais c’est un excellent point de départ avant de brancher votre pipeline d’analyse (SAST/linters) ou de préparer un profilage SQL (voir : PrestaShop debug profiling : activer et analyser performances SQL).
Pour donner une dimension « exploitable » à ces recherches, associez-leur une action. Exemple simple qui marche bien en revue :
- Hit SQL « concaténé » → ouvrir un ticket « vérifier requête paramétrée / DbQuery / escaping ».
- Hit override → exiger une justification (ou un plan de suppression).
- Hit superglobales → imposer une revue de validation + CSRF (et tests).
Pour le contexte e-commerce UE (France/Belgique/Suisse), un angle souvent oublié est la surface tracking/cookies (qui se répercute sur les parcours consentement). Une recherche basique aide à inventorier ce qui pose question dans vos modules :
("setcookie(" OR "document.cookie" OR "gtag(" OR "fbq(") org:votre-org -path:vendor/
Objectif : inventaire rapide, pas jugement — la conformité nécessite ensuite une analyse fonctionnelle.
Recherches enregistrées : industrialiser la veille (maintenance, sécurité, migration) sans réinventer des runbooks
Les recherches enregistrées (saved searches) sont sous-utilisées parce qu’elles ne « font rien » tant que vous ne les alimentez pas dans un process. L’idée n’est pas de bookmarker une URL ; c’est de figer une requête critique (dette, sécurité, compatibilité) et de la réexécuter pendant un sprint, une migration ou une fenêtre de patch. GitHub propose une fonctionnalité dédiée dans l’UI (GitHub Docs — Saving searches). Vous stockez le nom et la requête, et vous évitez le copier-coller approximatif entre devs.
Concrètement, pour un parc de modules PrestaShop, vous pouvez créer un set minimal de recherches enregistrées, par exemple :
- « Accès superglobales PHP » :
/\$_(GET|POST|REQUEST|COOKIE)\b/ org:votre-org language:PHP - « Overrides présents » :
path:override/ org:votre-org - « Appels cURL brut » :
("curl_exec" OR "curl_setopt") org:votre-org language:PHP
Ce sont des signaux, pas des verdicts. Leur intérêt est organisationnel : au moment d’une migration vers PrestaShop 9 (Symfony 6.4 côté core), vous réexécutez les mêmes recherches à chaque PR majeure et vous stabilisez la revue. Dans une logique d’exploitation/maintenance, ça s’imbrique naturellement avec une approche plus globale de durcissement et de suivi des correctifs (voir : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées).
Petit cadre simple (type runbook) pour rendre les recherches enregistrées vraiment utiles :
- Quand exécuter ? (ex. à chaque release, chaque sprint, avant montée de version, après merge de grosses PR).
- Qui traite ? (tech lead, mainteneur module, référent sécu).
- Quel seuil ? (ex. “0 nouvelle occurrence”, pas “0 occurrence tout court”).
- Quelle action ? (ticket + label + échéance, ou justification dans la PR).
Enfin, les recherches enregistrées sont utiles pour la contribution open source : quand vous préparez une PR, vous gardez sous la main des requêtes de non-régression (ex. pas de nouveau die()/var_dump(), pas de secret commité). Pour le workflow de contribution PrestaShop, vous pouvez les relier à la discipline PR décrite ici : Documentation développeur PrestaShop : contribuer en open source via pull request.
Automatiser la recherche : API GitHub, quotas, et usage réaliste dans une CI
Quand vous devez passer de l’interactif au reproductible (contrôle qualité), vous finissez généralement sur l’API. L’API REST expose des endpoints de recherche (API REST — Search). Pré-requis explicites : un token (PAT ou GitHub App) avec les scopes nécessaires selon public/privé, et une gestion des rate limits (le point qui casse les jobs CI « naïfs »).
Deux limites pratiques reviennent souvent :
- Rate limit spécifique à la recherche : les endpoints de recherche ont un quota dédié (différent du quota REST général), à respecter si vous ne voulez pas des builds intermittents.
- Résultats plafonnés : via l’API Search, vous ne pourrez pas « itérer sur tout » indéfiniment ; il faut penser en termes d’échantillonnage utile, ou basculer sur des scans locaux quand vous avez besoin d’exhaustivité.
Exemple minimal (à adapter) pour lancer une recherche code via REST et récupérer les 10 premiers items. À exécuter dans un job GitHub Actions, GitLab CI ou un runner interne ; attention à ne jamais logguer le token :
curl -sS -H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_TOKEN" \
"https://api.github.com/search/code?q=path:override/+repo:votre-org/votre-boutique" \
| jq '.items[0:10] | map({name: .name, path: .path, html_url: .html_url})'
L’usage réaliste en CI n’est pas « on bloque le build sur 1 match », sinon vous allez créer des faux positifs et contourner l’outil. Le pattern qui marche bien :
- exécuter la requête (ou un petit set de requêtes) ;
- publier les hits dans un artefact (JSON/Markdown) attaché au job ;
- gérer un budget : pas de nouvelle occurrence par rapport au main (approche différentielle) ;
- rendre visible dans la review (commentaire de bot, checklist PR, label).
Cette approche s’aligne avec des pipelines plus complets (SBOM, provenance, policy) : CI PrestaShop : provenance, SBOM et validation automatique des modules et Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible.
Dernier point : l’API de recherche n’est pas un moteur d’analyse statique. Elle ne comprend pas votre modèle de données, ne suit pas l’exécution, et ne remplacera jamais un scanner de secrets ou un SAST. Utilisez-la comme une brique de détection large (surface), puis basculez sur des outils faits pour la précision (profondeur).
Jeux de requêtes prêts à l’emploi (à transformer en recherches enregistrées)
Pour éviter les requêtes « one shot » qui se perdent, prenez 30 minutes et transformez un set de recherches en recherches enregistrées. Objectif : couvrir les axes qui cassent réellement des projets PrestaShop en prod (migrations, perf, sécu, maintenabilité). Le fait d’avoir des requêtes standardisées vous permet aussi de mieux briefer une intervention externe (revue d’un module, audit), au même titre qu’un brief technique bien cadré côté projet.
Voici une base de départ (à adapter à votre org, vos conventions et vos branches) :
# Hooks / extension
"registerHook" org:votre-org language:PHP
"Hook::exec" org:votre-org language:PHP -path:vendor/
# Overrides (surface de risque)
path:override/ org:votre-org
# Symfony (services, controllers)
filename:services.yml org:votre-org
path:src/Controller org:votre-org language:PHP
# Templates
extension:tpl org:votre-org
extension:twig org:votre-org
# SQL brut / concat
("SELECT " OR "UPDATE " OR "INSERT ") org:votre-org language:PHP -path:vendor/
("_DB_PREFIX_" AND "." ) org:votre-org language:PHP
# Accès superglobales
/\$_(GET|POST|REQUEST|COOKIE|FILES)\b/ org:votre-org language:PHP
# Debug oublié
("var_dump" OR "dd(" OR "die(" ) org:votre-org -path:vendor/
# Workflows CI
path:.github/workflows org:votre-org
Ajouts utiles (souvent “quick wins” en e-commerce) :
- Appels réseau synchrones dans des chemins chauds :
("file_get_contents(" OR "curl_exec" OR "GuzzleHttp") org:votre-org language:PHP -path:vendor/
- Détection de patterns d’injection (pré-filtre ; à confirmer ensuite par revue) :
("WHERE " AND ".=") org:votre-org language:PHP -path:vendor/
Pour cadrer la priorisation, vous pouvez vous appuyer sur la catégorie Injection d’OWASP Top 10 : OWASP Top 10 — Injection
- Secrets “évidents” (à utiliser uniquement dans votre périmètre, et idéalement en complément de GitHub Secret Scanning) :
("BEGIN PRIVATE KEY" OR "AKIA" OR "xoxb-") org:votre-org -path:vendor/
Ne vous contentez pas de stocker ces requêtes : documentez l’action attendue quand il y a un hit (ex. « occurrence dans override/ ⇒ ticket de suppression ou justification », « superglobales ⇒ revue input validation + CSRF », « debug ⇒ correction avant release »). C’est ce qui transforme la recherche de code GitHub en outil d’ingénierie, pas en gadget de navigation.