Pages générées
714
Pages statiques générées après l’ajout des expertises, outils et routes localisées.
Preuve d’ingénierie
Bz Info n’est pas seulement un portfolio : c’est un système produit vérifiable.
Cette page expose la logique technique derrière la plateforme : architecture web, backend NestJS, qualité, tests, opérations, SEO, i18n et discipline de livraison.
Husky pre-pushESLint + Prettierportfolio-api/test9 quality phasesmodule runners.reports output
Langues actives
6
Français, anglais, arabe, espagnol, allemand et néerlandais avec routes dédiées.
Chaîne qualité
Typecheck + Build
Validation frontend systématique avant de figer les changements.
Backend quality is module-owned.
Each serious module can expose its own perf, contract, unit, integration, E2E, smoke, security and mutation phases.
Carte système
Une plateforme pensée comme un produit complet.
La preuve ne vient pas d’une seule page. Elle vient de l’ensemble : site public, API, admin, documentation, outils, contenus localisés et qualité.
01 · Visible
Public web
Next.js, routes localisées, SEO, sitemap, pages expertise et documentation.
02 · Architecture
Backend API
API NestJS pour contact, chatbot, analytics, communication et workflows produit.
03 · Operations
Admin system
Supervision future des demandes, conversations, logs, statistiques et opérations.
04 · Expansion
Tools lab
Packs développeur, scripts, passerelle SMS transactionnelle et IA locale.
Backend proof
Le backend est traité comme une colonne vertébrale produit.
L’objectif est de montrer la capacité à structurer des modules, contrats, validations, flux métier, sécurité et intégrations sans transformer le projet en vitrine fragile.
NestJS
Architecture modulaire
Modules, services, DTOs, guards, validation et contrats API maintenables.
Prisma
Persistance maîtrisée
Modèles, transactions, contraintes et séparation claire entre domaine et stockage.
Realtime
Flux vivants
Chat, support, notifications et interfaces admin reliées à l’état réel du système.
Communication
Email, SMS et notifications
Canaux transactionnels conçus avec limites, logs, sécurité et usages précis.
01
HTTP request
Controller receives a public operation through a documented route.
02
DTO validation
class-validator, Swagger metadata and ValidationPipe must stay aligned.
03
Guard / auth
Access rules, JWT context, throttling and role checks protect the boundary.
04
Service decision
Business rules are isolated, testable and protected by explicit branches.
05
Prisma / storage
Transactions, constraints and persistence shape are verified by tests.
06
Reports
Schemathesis, smoke, ZAP, k6 and Stryker expose behavior from outside.
Méthode backend
Une méthode progressive, valable quel que soit le framework.
NestJS, Spring Boot, Python, Go ou .NET : le principe reste le même. Comprendre, verrouiller, améliorer, mesurer, durcir, puis documenter.
01
Reconnaissance
Lire les routes, DTOs, guards, services, accès base de données, erreurs et contrats publics.
Comprendre le système avant de le modifier.
02
Refactor léger
Clarifier les responsabilités sans réécrire le produit ni casser le comportement existant.
Réduire la dette sans créer une migration risquée.
03
Tests de base
Verrouiller les comportements existants avec des tests simples mais utiles.
Créer un filet de sécurité avant les corrections profondes.
04
Tests profonds
Tester les branches, erreurs, limites, transactions, null, undefined et chemins d’exception.
Attaquer les angles morts que les tests superficiels ignorent.
05
Integration & E2E
Valider les frontières réelles entre API, authentification, base de données et services.
Prouver que le comportement fonctionne hors isolation.
06
Performance
Mesurer la latence, concurrence, contention DB, N+1, throttling, mémoire et chemins lents.
Identifier ce qui casse quand le backend n’est plus seul.
07
Contract testing
Utiliser OpenAPI et Schemathesis pour confronter le contrat public au comportement réel.
Corriger DTOs, Swagger, ValidationPipe et réponses documentées.
08
Runtime security
Ajouter smoke checks, ZAP, logs et vérifications runtime sur les comportements exposés.
Observer le système comme il tourne réellement.
09
Mutation testing
Utiliser Stryker pour vérifier que les tests tuent les changements de comportement.
Mesurer la force des tests, pas seulement leur couverture.
10
Documentation
Garder les commandes, rapports, runners et décisions dans une forme réutilisable.
Rendre la qualité transmissible à l’équipe et au futur projet.
Définition des tests
Chaque type de test couvre un risque différent.
La qualité backend n’est pas une pile de dossiers. Chaque phase répond à une question précise : est-ce correct, intégré, documenté, robuste, sécurisé et capable de résister au changement ?
00-static-quality
Static quality gate
Vérifie le typage, ESLint, Prettier, le build et les hooks Git avant de faire confiance au runtime.
When
Avant toute suite lourde, avant commit, avant push et avant d’analyser des erreurs plus complexes.
Why
Husky, ESLint et Prettier évitent de laisser entrer du bruit dans le dépôt : format cassé, dette de style, erreurs statiques ou build invalide.
01-perf
Performance
Mesure la latence, le taux d’erreur, la concurrence et les limites visibles quand l’API reçoit de la charge.
When
Avant de valider un module exposé, après un refactor sensible ou quand un endpoint touche la base de données.
Why
Un backend peut être fonctionnel en test unitaire mais lent, instable ou dangereux sous concurrence.
02-schemathesis
Schemathesis / OpenAPI
Attaque automatiquement les endpoints à partir du contrat OpenAPI publié par l’application.
When
Après avoir stabilisé les DTOs, Swagger, ValidationPipe et les statuts HTTP documentés.
Why
Révèle les écarts entre documentation, validation réelle et réponses envoyées aux clients.
03-unit
Unit tests
Isole une décision métier, un DTO, un service, un guard ou un mapper pour vérifier ses branches.
When
Au début du durcissement, avant les refactors profonds, et pour tuer les mutants Stryker.
Why
Verrouille les règles importantes sans dépendre du réseau, de la base ou de tout le module.
04-integration
Integration tests
Vérifie les frontières réelles entre modules, providers, transactions, base de données et services.
When
Quand la logique dépend de Prisma, d’un repository, d’une transaction ou d’une composition de services.
Why
Attrape les erreurs que les tests unitaires masquent avec des mocks trop optimistes.
05-e2e
E2E tests
Teste un parcours API complet depuis la requête HTTP jusqu’au comportement produit attendu.
When
Pour les flows critiques : auth, contact, admin, support, paiement, notification ou onboarding.
Why
Prouve que les couches controller, validation, auth, service et réponse fonctionnent ensemble.
06-smoke
Smoke tests
Vérifie rapidement que le système lancé répond et que les chemins critiques ne sont pas cassés.
When
Après build, déploiement local, changement d’environnement ou avant de lancer des tests plus lourds.
Why
Évite de lancer une suite coûteuse contre une API morte, mal configurée ou non joignable.
07-zap
ZAP security checks
Observe la surface HTTP exposée pour détecter des signaux de sécurité basiques ou des mauvaises réponses.
When
Sur les endpoints publics, admin, auth ou toute route exposée à des utilisateurs externes.
Why
Complète les tests fonctionnels avec une vision runtime de la surface attaquable.
08-mutation
Stryker mutation
Modifie le code automatiquement pour vérifier si les tests détectent les changements de comportement.
When
Après une bonne couverture unit/integration, quand on veut mesurer la force réelle des tests.
Why
Une couverture à 100% ne suffit pas ; Stryker vérifie que les assertions protègent vraiment le métier.
portfolio-api/test
Module-by-module quality factory
Each backend module owns the same quality surface, from contract checks to mutation testing, with a dedicated global runner and local README.
01
01-perf
Load, latency and concurrency baseline.
02
02-schemathesis
OpenAPI contract attack against real endpoints.
03
03-unit
DTOs, services, guards, modules and branch decisions.
04
04-integration
Database, providers and cross-service boundaries.
05
05-e2e
Real API flows through the application surface.
06
06-smoke
Runtime availability and critical path sanity checks.
07
07-zap
Basic exposed security signals.
08
08-mutation
Stryker mutation strength and test robustness.
Sample modules already shaped with this convention
admin-authadmin-dashboardadmin-supportaudit-logschatchatbotcontacthealthleadsmonitoringnotifications
test/<module>/
├── 01-perf
├── 02-schemathesis
├── 03-unit
├── 04-integration
├── 05-e2e
├── 06-smoke
├── 07-zap
├── 08-mutation
├── scripts/run-<module>-global.sh
└── README.mdbash
Global module runner
One command can run the module quality chain with explicit toggles.
MODULE_NAME="admin-auth"RUN_ADMIN_AUTH_SCHEMATHESIS="${RUN_ADMIN_AUTH_SCHEMATHESIS:-true}"RUN_ADMIN_AUTH_SMOKE="${RUN_ADMIN_AUTH_SMOKE:-true}"RUN_ADMIN_AUTH_UNIT="${RUN_ADMIN_AUTH_UNIT:-true}"RUN_ADMIN_AUTH_INTEGRATION="${RUN_ADMIN_AUTH_INTEGRATION:-true}"RUN_ADMIN_AUTH_E2E="${RUN_ADMIN_AUTH_E2E:-true}"RUN_ADMIN_AUTH_MUTATION="${RUN_ADMIN_AUTH_MUTATION:-true}"bash
Schemathesis contract attack
OpenAPI is fetched from the running API, then attacked in Docker.
SCHEMA_FETCH_URL="${SCHEMA_FETCH_URL:-http://localhost:4002/api/docs-json}"SCHEMATHESIS_BASE_URL="${SCHEMATHESIS_BASE_URL:-http://host.docker.internal:4002}"SCHEMATHESIS_PATH_REGEX="${SCHEMATHESIS_PATH_REGEX:-^/api/v1/admin/auth/(login|refresh|logout|me)$}"docker run --rm --add-host=host.docker.internal:host-gateway \ ghcr.io/schemathesis/schemathesis:stable run openapi-admin-auth.jsonjson
Stryker mutation gate
Mutation score is a hard quality threshold, not a vanity metric.
{ "testRunner": "jest", "mutate": ["src/modules/admin-auth/**/*.ts"], "coverageAnalysis": "perTest", "thresholds": { "high": 100, "low": 100, "break": 100 }}javascript
k6 health baseline
Performance tests expose latency and failure-rate risks outside unit isolation.
export const options = { thresholds: { http_req_failed: ["rate<0.01"], checks: ["rate>0.99"], "http_req_duration{endpoint:health}": ["p(95)<250", "p(99)<500"], },};Outil → risque
Chaque outil attaque une catégorie de risque différente.
La chaîne qualité n’est pas une accumulation de logos. Chaque étape a une raison précise et couvre un angle que les autres ne couvrent pas.
TypeScript
Erreurs statiques
Détecte les incohérences de types avant le runtime, surtout dans les DTOs, services et contrats internes.
Unit tests
Décisions métier fragiles
Verrouillent les règles importantes, les branches, les erreurs et les cas limites isolés.
Integration tests
Frontières invisibles
Vérifient les interactions entre services, transactions, base de données et dépendances internes.
E2E tests
Parcours API incomplets
Valident les flows réels depuis l’endpoint jusqu’au comportement attendu côté produit.
k6
Charge et concurrence
Expose les lenteurs, verrous, N+1, contention et comportements qui n’apparaissent pas en test isolé.
Schemathesis
Contrat OpenAPI faux
Révèle les écarts entre Swagger, DTOs, ValidationPipe, statuts HTTP et réponses réelles.
ZAP
Surface runtime exposée
Repère les signaux de sécurité basiques visibles depuis l’extérieur du système.
Stryker
Tests faibles
Prouve si la suite de tests détecte réellement les mutations de comportement.
Modèle de confiance
La confiance monte quand plusieurs risques sont attaqués.
Ce graphe est un modèle pédagogique, pas une statistique scientifique. Il montre comment la confiance augmente quand la validation couvre davantage d’angles.
Static
20%Le code compile et les erreurs évidentes sont réduites.
Unit
38%Les décisions métier principales commencent à être verrouillées.
Integration
55%Les frontières service/base/API deviennent plus sûres.
E2E
68%Les parcours réels sont validés de bout en bout.
Contract
80%Le contrat public est attaqué automatiquement.
Runtime
88%Performance, smoke et sécurité runtime ajoutent une vision réelle.
Mutation
95%La suite de tests prouve qu’elle détecte les changements dangereux.
Quality pipeline
La qualité est une chaîne, pas une décoration.
Chaque étape doit réduire une catégorie de risque : typage, contrat, comportement métier, runtime, sécurité ou robustesse des tests.
01
Static confidence
Vérifier le typage, le formatage, les conventions et les erreurs évidentes avant runtime.
TypeScriptESLintPrettierBuild
02
Behavior confidence
Tester les décisions métier, les intégrations et les parcours de bout en bout.
UnitIntegrationE2ESmoke
03
Contract confidence
Attaquer les contrats API et vérifier que la documentation reflète le comportement réel.
OpenAPISchemathesisSwaggerDTO validation
04
Hardening confidence
Chercher activement les faiblesses au lieu de se contenter d’un build vert.
StrykerZAPk6Audit logs
Ce que cela prouve
La valeur est dans la discipline répétée.
Cette page ne promet pas une perfection abstraite. Elle montre une méthode : structurer, vérifier, documenter, localiser, mesurer et refactoriser quand une limite apparaît.
Architecture lisible
Les pages, contenus, composants et routes sont séparés pour rester maintenables.
Refactor réel
Les fichiers trop grands sont divisés au lieu d’être acceptés comme dette silencieuse.
SEO vérifiable
Sitemap, canonical, hreflang et routes localisées sont traités comme des contrats publics.
Preuve par le produit
Le site lui-même démontre le niveau attendu : contenu, UI, architecture et validations.
Preuve exploitable
Un échange technique peut partir de preuves concrètes, pas seulement d’un discours.
Pour une mission backend, une reprise de projet ou une plateforme produit, cette page sert de point d’entrée technique.