En bref
Bruno est un excellent client API local avec de véritables atouts, mais il présente de réelles lacunes qui comptent en fonction de votre flux de travail. Pas de synchronisation cloud, pas de serveur de maquette (mock server), pas de documentation API, des fonctionnalités d'équipe limitées et des capacités de script plus faibles que Postman. Cette évaluation est honnête concernant chaque lacune et le moment où elle est réellement importante.
Introduction
Bruno a gagné sa réputation. Il est rapide, open source, sous licence MIT et stocke tout en texte brut compatible Git. La communauté GitHub est active, les mainteneurs sont réactifs, et le cas d'utilisation principal – créer et tester des requêtes HTTP localement – fonctionne bien.
Mais la philosophie du "sans superflu" a un coût. Certaines des fonctionnalités que Bruno n'a pas ne sont pas du superflu – ce sont des choses dont les vraies équipes ont réellement besoin. Cet article passe en revue honnêtement les principales limitations, explique quand chacune est importante et suggère ce qu'il faut utiliser à la place.
Limitation 1 : Pas de synchronisation cloud
Ce qui manque : Bruno n'a pas de mécanisme intégré pour synchroniser les collections entre les machines ou les membres de l'équipe. La fonctionnalité Bru Cloud a été annoncée comme un service payant optionnel, mais le produit principal reste local seulement.
Comment les équipes s'en sortent : Dépôts Git. Vous poussez votre dossier de collection vers GitHub, GitLab ou Bitbucket, et les membres de l'équipe le tirent. Cela fonctionne bien lorsque tout le monde a une bonne discipline Git.
Quand cela pose problème :
- Vous devez partager un test rapide avec un collègue qui n'utilise pas Git régulièrement
- Votre équipe comprend des ingénieurs QA ou des chefs de produit qui ne sont pas à l'aise avec les flux de travail Git
- Vous souhaitez effectuer un changement et qu'il soit répercuté sur la machine d'un coéquipier en moins d'une minute
- Vous travaillez sur plusieurs machines et souhaitez que les modifications se synchronisent automatiquement
Ce qu'il faut utiliser à la place : La synchronisation cloud optionnelle d'Apidog maintient les collections synchronisées au sein de l'équipe sans nécessiter un cycle de commit Git. Si un Git pur est acceptable, l'approche Bruno + Git convient aux équipes composées uniquement de développeurs.
Limitation 2 : Git est le seul mécanisme de collaboration d'équipe
Ce qui manque : Bruno n'a pas de concept d'espace de travail, pas de tableau de bord de projet partagé, pas de commentaires sur les requêtes, pas de contrôle d'accès basé sur les rôles. L'expérience "équipe" entière est médiatisée par Git.
Quand cela pose problème :
- Un membre de l'équipe crée un changement cassant pour une requête partagée et personne ne le sait avant qu'un problème ne survienne dans l'intégration continue
- Vous souhaitez attribuer des requêtes à des membres de l'équipe ou suivre qui a effectué un changement et pourquoi
- Les parties prenantes non développeurs (clients, rédacteurs techniques, chefs de produit) ont besoin d'un accès en lecture à la collection API sans compte Git
- Vous devez restreindre qui peut modifier les identifiants de l'environnement de production
Ce qu'il faut utiliser à la place : Les outils avec de véritables fonctionnalités d'espace de travail – Apidog vous offre le contrôle d'accès basé sur les rôles (RBAC), des espaces de travail partagés et des rôles de visionneur afin que les parties prenantes puissent accéder aux documents sans toucher aux collections.
Ce que Bruno offre réellement : L'historique Git complet est réellement utile. Chaque changement de chaque requête est suivi avec l'auteur, l'horodatage et le message de commit. C'est plus que ce que la plupart des outils offrent, mais ce n'est pas un substitut aux fonctionnalités de collaboration.
Limitation 3 : Pas de serveur de maquette (mock server) intégré
Ce qui manque : Bruno ne peut pas servir de réponses simulées. Il n'y a aucun moyen de dire à Bruno "agis comme le serveur API et renvoie ces réponses".
Quand cela pose problème :
- Le développement frontend dépend d'une API qui n'est pas encore construite
- Vous souhaitez exécuter des tests automatisés sur une maquette stable et prévisible plutôt que sur un environnement réel
- Votre environnement de staging est instable et vous souhaitez des tests isolés
- Les tests de contrat entre services nécessitent une maquette de l'API de chaque service
Ce qu'il faut utiliser à la place :
- Apidog Smart Mock – génère automatiquement des réponses de maquette à partir de votre spécification API
- WireMock – serveur de maquette autonome basé sur Java, plus de configuration mais très flexible
- MSW (Mock Service Worker) – excellent pour le développement frontend dans le navigateur
- Prism – serveur de maquette basé sur OpenAPI, d'abord en ligne de commande
L'absence de serveur de maquette est la limitation la plus courante citée par les utilisateurs de Bruno lorsque leurs équipes grandissent. C'est une absence réelle, pas juste "cachée dans un menu".
Limitation 4 : Pas de génération de documentation API
Ce qui manque : Bruno ne peut pas générer de documentation API à partir de vos collections. Il n'y a pas d'URL de documentation hébergée, pas d'exportation vers HTML ou Markdown, pas de génération de schéma OpenAPI.
Quand cela pose problème :
- Vous devez partager la documentation API avec des développeurs externes ou des partenaires
- Votre équipe rédige manuellement la documentation API dans un outil distinct (coût de maintenance élevé)
- L'intégration de nouveaux développeurs signifie les diriger vers une page Notion ou un document Confluence qui s'éloigne de la vraie API
- Vous devez publier une référence API publique
Ce qu'il faut utiliser à la place :
- Apidog – génère et héberge la documentation API directement à partir de la spécification, la maintient synchronisée
- Stoplight – plateforme de conception et de documentation API
- Redoc ou Swagger UI – documentation auto-hébergée à partir de spécifications OpenAPI
Beaucoup d'équipes ne pensent pas initialement avoir besoin de la génération de documents. Elles reconsidèrent lorsque l'intégration prend trois heures par nouveau développeur.
Limitation 5 : Des capacités de script plus faibles que Postman
Ce qui est disponible dans Bruno : Scripts de pré-requête et de post-réponse en JavaScript, utilisant l'espace de noms bru. Vous pouvez définir des variables, enchaîner des requêtes, écrire des assertions avec Chai, et faire la plupart des choses courantes.
Ce qui manque par rapport à Postman :
- Pas de bibliothèque d'utilitaires pré-construits à la manière de Postman
- L'espace de noms
bruest moins documenté que lepmde Postman require()à l'intérieur des scripts a des limitations (l'accès aux built-ins de Node est restreint par défaut)- Pas de constructeur de script GUI pour les non-développeurs
- Les messages d'erreur dans les scripts échoués sont moins descriptifs
Quand cela pose problème :
- Flux d'authentification complexes nécessitant plusieurs calculs de pré-requête
- Scripting pour les développeurs qui préfèrent l'API plus étendue de Postman
- Ingénieurs d'automatisation QA qui ont construit des bibliothèques de scripts Postman élaborées
Solution de contournement : La plupart des scripts Postman se convertissent en Bruno avec un échange d'espace de noms (pm. devient bru.). Les scripts avec des dépendances require() complexes nécessitent plus de travail.
Limitation 6 : Pas de fonctionnalités d'entreprise
Ce qui manque : Pas de SSO (SAML, LDAP), pas de journaux d'audit, pas d'exportations de conformité, pas de console d'administration, pas de permissions granulaires au-delà de Git.
Quand cela pose problème :
- Environnements d'entreprise où l'IT exige le SSO pour tous les outils
- Audits de sécurité nécessitant des journaux de qui a accédé à quelles informations d'identification API
- Industries réglementées (finance, santé) avec des exigences de conformité
- Grandes organisations (plus de 50 développeurs) où la gestion des accès est importante
C'est une décision produit délibérée, pas un oubli. Bruno n'essaie pas d'être un produit d'entreprise.
Ce qu'il faut utiliser à la place : Apidog pour les équipes qui ont besoin de RBAC. Postman Enterprise ou Insomnia Enterprise pour les organisations qui ont besoin de toutes les fonctionnalités de conformité d'entreprise.
Limitation 7 : Uniquement sur bureau, pas d'interface web
Ce qui manque : Bruno n'a pas d'application web. Vous ne pouvez pas l'ouvrir dans un navigateur, partager une URL de collection en direct ou l'utiliser sur une machine où vous ne pouvez pas installer de logiciel.
Quand cela pose problème :
- Vous travaillez depuis une machine d'entreprise verrouillée où vous ne pouvez pas installer de logiciel
- Vous souhaitez partager une collection API exécutable avec quelqu'un qui n'a pas Bruno installé
- Votre équipe utilise des Chromebooks ou des clients légers
- Vous avez besoin d'un accès basé sur le navigateur pour une raison de conformité spécifique
Ce qu'il faut utiliser à la place : Apidog dispose à la fois d'une application de bureau et d'une interface web. Hoppscotch est basé sur le navigateur et open source si vous avez spécifiquement besoin d'un client web.
FAQ
Vaut-il toujours la peine d'utiliser Bruno malgré ces limitations ?Oui, pour le bon cas d'utilisation. Les développeurs individuels et les petites équipes avec une bonne discipline Git obtiennent un outil rapide, gratuit et respectueux de la vie privée qui fait bien le travail essentiel. Les limitations ne mordent que lorsque vous avez besoin de fonctionnalités que Bruno omet délibérément.
Bruno ajoutera-t-il la synchronisation cloud à terme ?Bru Cloud a été annoncé comme un niveau payant optionnel. Quand et comment il sera livré reste à voir. L'application principale devrait rester locale d'abord.
Puis-je utiliser Bruno pour la conception d'API (écriture de spécifications OpenAPI) ?Non. Bruno est un client API, pas un outil de conception d'API. Vous ne pouvez pas écrire ou valider des spécifications OpenAPI dans Bruno. Utilisez Apidog, Stoplight ou un éditeur de code avec une extension OpenAPI pour la conception d'API.
Bruno prend-il en charge WebSocket ou gRPC ?Le support de WebSocket est limité. gRPC n'est pas pris en charge dans la version stable actuelle. Si votre équipe utilise gRPC de manière extensive, Bruno n'est pas le bon outil.
Y a-t-il des plans pour ajouter un serveur de maquette à Bruno ?Pas d'élément de feuille de route officiel pour un serveur de maquette intégré en date de 2026. La philosophie des mainteneurs privilégie de bien faire quelques choses plutôt que d'étendre la portée.
Comment Bruno se compare-t-il à Insomnia pour les équipes ?Insomnia a la synchronisation cloud et un plan d'équipe payant. Il est plus proche de Postman en termes de fonctionnalités. Bruno est plus minimal. Pour les équipes qui ont spécifiquement besoin de la synchronisation cloud sans passer à Apidog ou Postman, Insomnia mérite d'être considéré.
Les limitations de Bruno ne sont pas des bugs – elles sont le résultat de choix de conception délibérés. Connaître ces choix à l'avance vous évite de les découvrir en plein milieu d'un projet.
