Aller au contenu

Lexique

Le jargon, en français clair.

Définitions courtes des termes qu’on utilise sur ce site. Quand une fiche du socle va plus loin, on y renvoie.

  • API

    Interface qui permet à des logiciels de communiquer entre eux (échanger des données, déclencher des actions) de façon standardisée.

    Fiche socle →

  • API Gateway

    Porte d’entrée unique devant plusieurs services : authentification, limitation de trafic, routage. Le client parle à la gateway, pas à chaque service.

    Fiche socle →

  • Authentification

    Vérifier qui est l’utilisateur (ou le système) qui appelle — et quels droits il a. Souvent couplée à l’autorisation (ce qu’il peut faire).

  • Audit build

    Mission courte (souvent ~5 jours) pour cartographier l’existant, les risques et un backlog priorisé, puis chiffrer une phase 1. Ce n’est pas un audit « papier » : il prépare le build.

  • Backlog

    Liste ordonnée des travaux à faire (fonctionnalités, correctifs, dettes). On priorise pour livrer d’abord ce qui réduit le risque ou débloque le métier.

  • BDD

    Approche où les critères métier sont écrits en langage lisible (souvent Gherkin) et peuvent être exécutés par la CI. Le décideur lit ; la machine vérifie.

    Fiche socle →

  • Brief

    Appel gratuit de 45 minutes pour clarifier le problème, l’urgence, la stack actuelle et le go/no-go — avant tout audit ou devis de build.

  • CI/CD

    Intégration et déploiement continus : à chaque merge, la machine build, teste et contrôle — pour qu’un déploiement soit possible sans « ça marche sur ma machine ».

    Fiche socle →

  • CQRS

    Séparer les modèles de lecture et d’écriture quand les parcours divergent (perf, clarté des responsabilités). Pas un dogme : utile quand le besoin le justifie.

    Fiche socle →

  • CVE

    Identifiant public d’une faille de sécurité connue (Common Vulnerabilities and Exposures). On les scanne en CI (ex. Trivy) pour corriger avant la prod.

    Fiche socle →

  • DDD

    Concevoir le logiciel autour du langage et des règles du métier (le « domaine »), pour des décisions plus stables et moins de jargon opaque entre métier et tech.

    Fiche socle →

  • Gherkin

    Langage structuré (Given / When / Then) pour écrire des scénarios métier exécutables. Sert de pont entre le décideur et la CI.

    Fiche socle →

  • Legacy

    Système existant difficile à faire évoluer (dette, silos, peu de tests). On le modernise par étapes, sans tout réécrire d’un coup sauf contrainte forte.

  • Microservices

    Plusieurs petites applications qui se parlent en réseau, souvent déployées séparément. Plus flexible pour scaler ou paralléliser les équipes — mais plus complexe à opérer.

    Fiche socle →

  • Monolithe modulaire

    Une seule application (un déploiement), découpée en modules clairs (ex. facturation, utilisateurs). Choix par défaut : simple à faire tourner, évolutif sans microservices prématurés.

    Fiche socle →

  • MVP

    Minimum Viable Product : la plus petite version utilisable qui valide le besoin réel — pas une démo jetable, un livrable qui peut vivre en production.

  • Observabilité

    Capacité à comprendre ce qui se passe en production via des signaux (erreurs, traces, usage produit, disponibilité) — pour agir, pas pour décorer un dashboard.

    Fiche socle →

  • PHPStan

    Analyseur statique PHP : détecte des erreurs et incohérences de types avant la revue humaine et avant la prod.

    Fiche socle →

  • Playwright

    Outil de tests navigateur automatisés pour les parcours critiques (clics, formulaires, flux métier) — filet de régression côté interface.

    Fiche socle →

  • POC

    Proof of Concept : expérience courte pour prouver qu’une idée technique ou métier est viable. Ensuite il faut un vrai chemin vers MVP / prod, sinon ça reste une démo.

  • Rate-limit

    Plafond sur le nombre de requêtes autorisées (par utilisateur, IP ou clé API). Protège contre les abus et les pics qui font tomber le service.

    Fiche socle →

  • Reverse proxy

    Serveur placé devant l’application (ex. Nginx, Caddy) : HTTPS, routage simple, parfois cache. Suffit souvent quand on n’a pas une vraie architecture multi-services.

  • Run

    La vie du produit après la mise en production : correctifs, petites évolutions, monitoring, disponibilité. Souvent couvert par une TMA / forfait run optionnel.

  • SPA

    Application web dont l’interface se charge une fois puis navigue sans recharger toute la page (souvent React). Utile pour les parcours riches ; pas obligatoire pour une vitrine.

    Fiche socle →

  • Stack

    Ensemble des technologies choisies pour un projet (langages, frameworks, bases, CI, hébergement). Chez nous : documentée, choisie projet par projet, pas une muraille de logos.

  • TDD

    Écrire les tests (ou les critères) avant ou avec le code pour protéger les comportements critiques. Objectif : pouvoir changer sans tout casser.

    Fiche socle →

  • TMA

    Tierce Maintenance Applicative : forfait optionnel après livraison (correctifs, évolutions, monitoring). Le code reste à vous — pas de location d’une boîte noire.

Next · Loading

Un outil qui coince ?

Un Brief de 45 minutes, gratuit. On clarifie le périmètre — puis un audit build si ça tient la route.

STATUS: READY SIGNAL: OPEN WHOAMI → BRIEF
Réserver un Brief 45 min