Guide d'utilisation de LoadForge
Tout ce qu'il faut pour tester la capacité de votre SaaS : de l'inscription à la lecture du Capacity Score, en passant par la vérification de domaine.
Démarrage
Introduction
LoadForge est une plateforme de Performance Intelligence : elle simule un trafic important sur votre application pour répondre à une question simple — « Jusqu'à combien d'utilisateurs mon SaaS tient-il avant de ralentir ou casser ? »
Elle transforme des métriques techniques en décisions claires :
Capacity Score
Une note de 0 à 100 sur la santé sous charge.
Breaking Point
Le nombre d'utilisateurs où l'app devient instable.
Zone de dégradation
Là où la latence et les erreurs augmentent.
Launch Readiness
Êtes-vous prêt pour votre prochain lancement ?
Démarrage rapide
Le parcours complet, en 5 étapes :
Créez un compte
Inscription par email — un workspace est créé automatiquement.
Ajoutez votre application
Renseignez l'URL publique de votre SaaS et ses environnements (Production, Staging).
Vérifiez le domaine
Prouvez que vous contrôlez la cible (DNS ou fichier). Obligatoire avant tout test.
Lancez un test
Choisissez le type, le nombre d'utilisateurs virtuels et la durée, puis lancez.
Analysez
Capacity Score, Breaking Point et recommandations. Corrigez, retestez, suivez l'évolution.
Compte & workspace
Un workspace regroupe vos projets, membres et facturation. Il est créé à l'inscription ; vous pouvez en avoir plusieurs (ex. un par client si vous êtes une agence).
| Rôles | Owner, Admin, Éditeur, Lecteur — l'Éditeur et plus peuvent lancer des tests. |
| Membres | Invitez votre équipe depuis Membres. |
| Facturation | Le plan s'applique au workspace (voir Plans). |
Ajouter une application
Depuis Projets → Nouveau projet, renseignez :
| Nom | Le nom de votre application. |
| URL de base | L'adresse publique, ex. https://mon-app.com. |
| Environnements | Production et/ou Staging, chacun avec sa propre URL. |
Testez d'abord le Staging
Si vous avez un environnement de préproduction, vérifiez-le et testez-le en premier. Vous validerez votre configuration sans risque pour vos vrais utilisateurs.Vérification
Vérifier le domaine
Avant de lancer un test, vous devez prouver que vous contrôlez le domaine ciblé. C'est une sécurité : elle empêche d'utiliser LoadForge pour envoyer du trafic sur le site de quelqu'un d'autre.
Tant que ce n'est pas fait, le message « Aucun environnement vérifié » s'affiche et le test est bloqué. Deux méthodes au choix :
| DNS TXT | Ajoutez un enregistrement dans votre zone DNS. Recommandé, surtout pour les apps (SPA) qui renvoient du HTML sur toutes les URL. |
| Fichier HTTP | Hébergez un fichier à la racine du site. Simple si vous pouvez déposer des fichiers statiques. |
Méthode DNS TXT
Dans la zone DNS de votre domaine, ajoutez un enregistrement :
| Type | TXT |
| Nom / Host | le nom affiché dans l'écran de vérification, ex. _loadforge.mon-app.com |
| Valeur | loadforge-verification=VOTRE_TOKEN |
Piège n°1 : les sous-domaines
Si votre app est sur un sous-domaine (ex.planner.mon-app.com), l'enregistrement doit être sur_loadforge.planner.mon-app.com — pas sur le domaine racine.
Chez beaucoup d'hébergeurs (LWS, OVH…) la zone DNS est celle du domaine racine. Pour cibler le sous-domaine, mettez dans le champ « sous-domaine » la valeur _loadforge.planner (l'hébergeur ajoute.mon-app.com tout seul).
Piège n°2 : la valeur
La valeur doit inclure le préfixeloadforge-verification=. Mettre uniquement le token ne fonctionne pas.Vérifiez vous-même avant de cliquer « Vérifier » :
dig TXT _loadforge.mon-app.com +short # doit renvoyer : "loadforge-verification=VOTRE_TOKEN"
La propagation DNS peut prendre de quelques minutes à quelques heures.
Méthode fichier HTTP
Rendez ce fichier accessible sur votre site :
https://mon-app.com/.well-known/loadforge-verification.txt
Son contenu doit être exactement le token affiché (rien d'autre). Selon votre stack :
| Next.js / React | Créez public/.well-known/loadforge-verification.txt, puis redéployez. |
| Site statique | Placez le fichier dans un dossier .well-known à la racine publiée. |
| Serveur (Nginx/Apache) | Déposez le fichier dans la racine web, ex. /var/www/mon-app/.well-known/. |
Attention aux SPA
Une application monopage (React/Vue/Next en mode SPA) renvoie souventindex.html (HTTP 200) pour toute URL inconnue. La vérification verra alors du HTML au lieu du token et échouera. Dans ce cas, utilisez plutôt la méthode DNS.Vérifiez :
curl -i https://mon-app.com/.well-known/loadforge-verification.txt # attendu : HTTP 200 + le token (pas de redirection, pas de HTML)
200.Dépannage de la vérification
| « Aucun enregistrement TXT trouvé » | Le nom est incorrect (souvent : mis sur le domaine racine au lieu du sous-domaine), ou la propagation DNS n'est pas terminée. |
| « Le contenu ne correspond pas » | Valeur DNS sans le préfixe loadforge-verification=, ou fichier HTTP renvoyant du HTML. |
| « HTTP 3xx / redirection » | Le fichier est derrière une redirection. Testez l'URL https finale directement. |
| « Cible interne/privée bloquée » | Le domaine résout vers une IP privée ou localhost — non autorisé (voir Sécurité). |
dig ou curl avant de cliquer « Vérifier ». Si votre outil voit la bonne valeur, LoadForge la verra aussi.Tester
Créer un test
Choisissez un type de test :
| Test rapide | Une charge fixe (nombre d'utilisateurs constant). Idéal pour valider un niveau précis. |
| Find Breaking Point | La charge augmente par paliers jusqu'à trouver la limite. Le mode phare de LoadForge. |
| Durée personnalisée | Contrôle total sur le timing (montée, plateau). |
Puis réglez les paramètres :
| Environnement | Un environnement vérifié (Production/Staging). |
| VUs | Le nombre d'utilisateurs virtuels simultanés (borné par votre plan). |
| Durée | La durée du test, en secondes. |
| Ramp-up | Le temps de montée en charge progressive. |
| Méthode / Endpoint | Ex. GET / ou POST /api/checkout. |
Commencez petit
Pour un premier test sur une app en production, commencez modeste (ex. 30 VUs, 30 s) puis augmentez. Testez de préférence en heures creuses.Suivi en temps réel
Une fois lancé, l'écran Test en cours affiche en direct (via un flux SSE) : utilisateurs actifs, requêtes/seconde, latence P95/P99, taux d'erreur et progression.
Le bouton Arrêter le test interrompt immédiatement l'exécution (kill switch). Le test bascule ensuite vers ses résultats.
Comprendre les résultats
Le Capacity Score (0–100) résume la santé de l'app sous charge. Il combine 5 dimensions :
| Reliability | Capacité à maintenir un faible taux d'erreur. |
| Latency | Stabilité des temps de réponse (P95). |
| Throughput | Volume de requêtes traitées. |
| Scalability | Maintien des performances quand la charge monte. |
| Stability | Absence de dégradation brutale / débit régulier. |
Vous obtenez aussi trois seuils clés :
| Capacité recommandée | Le trafic supporté dans de bonnes conditions. |
| Zone de dégradation | Le niveau où latence/erreurs commencent à monter. |
| Breaking Point | Le niveau où l'app devient significativement instable. |
Breaking Point Engine
En mode Find Breaking Point, la charge grimpe par paliers (ex. 500 → 2 500 → 5 000 → 10 000 VUs). LoadForge surveille le taux d'erreur, le P95/P99 et la stabilité, et identifie automatiquement où l'application décroche.
Le tableau des paliers classe chaque niveau en 🟢 Stable, 🟡 Dégradation ou 🔴 Instable.
Launch Readiness
Vous préparez un événement (campagne, lancement produit, pic médiatique) ? Renseignez le trafic attendu et LoadForge compare avec votre capacité mesurée :
| READY | Votre capacité couvre le trafic prévu avec une marge de sécurité. |
| NOT READY | La capacité est insuffisante — des actions correctives sont proposées. |
Référence
Sécurité
La sécurité est au cœur de LoadForge :
| Vérification obligatoire | Aucun test sans domaine vérifié. |
| Cibles interdites | localhost, IP privées (10.x, 192.168.x…), cloud metadata (169.254.169.254) sont bloqués. |
| Isolation | Chaque test s'exécute dans un environnement isolé (worker Docker). |
| Quotas | VUs, durée et fréquence sont limités par votre plan. |
| Kill switch | Un test peut être interrompu immédiatement à tout moment. |
| Journalisation | Création, lancement, annulation et erreurs sont tracés. |
Ne testez que ce qui vous appartient
Un test génère du vrai trafic. Ne lancez des tests que sur des applications que vous possédez ou êtes explicitement autorisé à charger.Plans & limites
| Free — 0 $ | 100 VUs · durée courte · 1 projet · rapports basiques. |
| Starter — 19 $ | 1 000 VUs · historique · Capacity Score. |
| Pro — 59 $ | 10 000 VUs · Breaking Point Engine · comparaison · scénarios. |
| Scale — 199 $ | Volume élevé · équipes · fonctionnalités avancées. |
| Enterprise | Sur devis · SSO · SLA · limites personnalisées. |
FAQ
Puis-je tester une app en local (localhost) ?
Non directement : les cibles internes sont bloquées. Exposez-la via un tunnel (ngrok, cloudflared) et utilisez l'URL publique.
La vérification échoue alors que j'ai tout ajouté ?
Le plus souvent, l'enregistrement est sur le mauvais niveau (racine au lieu du sous-domaine) ou la valeur n'a pas le préfixe loadforge-verification=. Voir la section Dépannage.
Combien de temps dure un test ?
Vous choisissez la durée. Un test de validation dure généralement de 30 s à quelques minutes.
Le test va-t-il ralentir mes vrais utilisateurs ?
Il génère un trafic réel. Commencez petit, testez le staging d'abord, et de préférence en heures creuses.
Prêt à tester votre SaaS ?
Créez un compte, vérifiez votre domaine et lancez votre premier test en quelques minutes.