Beex

Les équipes métier passent leur temps à bricoler des tableurs, des formulaires et des outils internes qui ne se parlent pas. Beex part d'une idée simple : leur donner des blocs qu'elles assemblent elles-mêmes pour construire ces outils, sans attendre un développeur. C'est le produit pour lequel nous avons créé HDM-SOFT en août 2024.

Le défi n'est pas seulement technique. Un produit no-code doit être assez souple pour couvrir des cas qu'on n'a pas prévus, et assez cadré pour qu'un utilisateur non technique ne se perde pas.

Je suis cofondateur et développeur full-stack. Sur le front, je porte l'architecture des modules : chaque fonctionnalité est un bounded context isolé, avec ses entités, ses cas d'usage et ses composants, et des règles de dépendance strictes entre couches. J'ai aussi écrit les conventions que l'équipe applique en revue de code.

Côté produit, je participe aux arbitrages : ce qu'on construit, ce qu'on refuse, dans quel ordre.

Le front est une application React et TypeScript découpée en modules, chacun organisé en quatre couches : domaine, application, infrastructure, interface. Les appels réseau passent par un client HTTP partagé, des DTO et des mappers, pour que le domaine ne dépende jamais d'un format d'API.

Le back expose des services métier et une base PostgreSQL. L'ensemble est conteneurisé et déployé sur Kubernetes, avec des images versionnées et une chaîne CI/CD sur Azure DevOps.

Structurer une base de code partagée dès le départ coûte cher au début et rapporte à chaque nouvelle fonctionnalité. Les conventions écrites valent mieux que les conventions orales : elles se relisent, se discutent et se font respecter en revue.

J'ai aussi appris qu'un produit no-code est d'abord un problème de conception d'interface. Le code n'est que la moitié du travail.