Dépasser les 200 outils est un jalon visible, mais ce nombre ne résume pas l’objectif de Bethemesh. Ajouter un 201e convertisseur n’a de valeur que s’il répond à un besoin réel. À mesure que le catalogue grandit, un autre enjeu devient plus important : faire en sorte que les outils puissent participer à des workflows cohérents plutôt que de rester des pages isolées.
C’est le passage d’une boîte à outils à une plateforme d’outils composables.
Un outil reste la meilleure interface pour un besoin simple
La composabilité ne signifie pas que chaque utilisateur doit construire un pipeline.
Pour calculer un pourcentage, convertir une unité ou effectuer une transformation ponctuelle, une page dédiée reste souvent l’interface la plus rapide.
Bethemesh conserve donc cette première couche : choisir un outil, fournir les données nécessaires et récupérer le résultat.
Ce modèle est simple à comprendre et particulièrement adapté aux usages occasionnels.
Le problème apparaît quand les opérations s’enchaînent
Prenons une image destinée au Web. L’utilisateur peut vouloir :
- la redimensionner ;
- la convertir ;
- la compresser ;
- récupérer le fichier final.
Si chaque étape existe uniquement sous forme de page indépendante, il faut télécharger puis réimporter le résultat à chaque fois.
Le même problème apparaît avec les données :
import CSV → nettoyer → supprimer doublons → trier → exporter
ou avec l’audio :
import → découper → normaliser → fondu → export
La valeur d’une plateforme augmente lorsque ces opérations peuvent partager des contrats compatibles.
Des moteurs réutilisables plutôt que trois implémentations
Une transformation utile peut apparaître à plusieurs endroits :
- outil autonome ;
- widget intégrable ;
- module du Workspace ;
- étape d’un pipeline.
L’enjeu architectural consiste à éviter que chacune de ces surfaces réimplémente la même logique.
Lorsque le moteur est partagé, la page outil et le pipeline deviennent deux interfaces différentes vers la même capacité. Cela facilite aussi les tests : corriger le moteur bénéficie à toutes les surfaces qui l’utilisent.
Le Workspace comme couche de composition
Le Workspace sert à assembler les modules.
Il répond à une situation intermédiaire : le besoin est trop complexe pour une opération unique, mais l’utilisateur veut encore expérimenter l’ordre et les paramètres.
Cette approche transforme la manière de penser le catalogue. Une nouvelle fonctionnalité n’est plus seulement évaluée selon la question :
Cette page serait-elle utile ?
mais aussi :
Cette transformation peut-elle recevoir la sortie d’un autre module et produire une donnée exploitable par la suite ?
C’est une exigence plus forte.
Les pipelines comme recettes
Lorsque le workflow est stabilisé, il peut devenir un pipeline réutilisable.
Le pipeline mémorise la recette : modules, ordre, paramètres. L’objectif est de pouvoir reproduire une méthode sans reconstruire toute la chaîne.
Cette logique est particulièrement utile pour les tâches récurrentes :
- préparer des images avec les mêmes dimensions ;
- nettoyer périodiquement un export ;
- appliquer plusieurs transformations audio ;
- convertir et structurer des données.
Pourquoi Audio a été une étape importante
L’audio a obligé Bethemesh à dépasser les transformations textuelles ou tabulaires simples.
Découpage, volume, normalisation, vitesse, fondus, canaux, fréquence d’échantillonnage et conversions de formats posent des questions de types, de fichiers, de performances et d’enchaînement.
Le résultat est intéressant au-delà de l’audio : renforcer les contrats des moteurs et du Workspace prépare d’autres familles de transformations plus riches.
La catégorie Audio illustre ainsi l’intérêt de construire une famille cohérente plutôt qu’une succession de convertisseurs sans relation.
Construction : un autre type de croissance
Les calculateurs de Construction & travaux montrent l’autre facette du catalogue.
Ici, la valeur n’est pas nécessairement dans un pipeline de fichiers. Elle vient de calculateurs spécialisés répondant à des besoins précis : surfaces, volumes, quantités et marges.
Cela rappelle une règle importante : tout n’a pas besoin d’être composable de la même façon.
Un bon calculateur autonome reste un bon produit. Le Workspace doit être utilisé là où l’enchaînement apporte une vraie valeur.
La composabilité ne concerne pas uniquement les pipelines.
Un outil peut aussi être proposé sous forme de widget intégrable. L’objectif est alors de réutiliser une capacité Bethemesh dans un autre contexte sans dupliquer tout son fonctionnement.
On obtient trois modes complémentaires :
| Surface |
Usage |
| Outil |
résoudre immédiatement un besoin |
| Widget |
intégrer une capacité ailleurs |
| Workspace / pipeline |
combiner plusieurs capacités |
Local First comme contrainte structurante
Bethemesh cherche à effectuer localement les traitements qui peuvent raisonnablement l’être. Cette décision influence les moteurs choisis, les formats supportés et la manière de construire les workflows.
Un pipeline composé de modules locaux peut traiter un fichier sans que chaque étape implique un aller-retour réseau.
Cette approche ne supprime pas tous les usages serveur. La synchronisation optionnelle, par exemple, peut servir à retrouver des recettes. Mais elle permet de séparer clairement la donnée traitée et la configuration du traitement.
Le principe est détaillé dans Pourquoi Bethemesh fonctionne en Local First.
Plus d’outils, mais pas à n’importe quel prix
Le nombre d’outils reste un indicateur facile à afficher. Ce n’est pas un indicateur suffisant de qualité.
Un catalogue utile doit éviter :
- les doublons artificiels ;
- les variantes qui n’apportent aucune intention de recherche ou d’usage différente ;
- les outils impossibles à maintenir ;
- les fonctions dont l’interface est plus complexe que le problème ;
- les transformations isolées alors qu’un moteur commun existe déjà.
La croissance doit donc être accompagnée d’audits du catalogue, de la taxonomie, du contenu éditorial et des possibilités de composition.
Le contenu éditorial comme quatrième couche
Plus de 200 outils créent aussi un problème de découverte. Un utilisateur ne pense pas toujours en nom d’outil.
Il pense :
Comment préparer toutes mes images avant de les publier ?
ou :
Comment calculer les matériaux de mon chantier ?
Les guides et tutoriels relient plusieurs outils autour d’un objectif. Ils jouent donc un rôle similaire aux pipelines, mais sur le plan éditorial : ils organisent des capacités dispersées en un parcours compréhensible.
Ce qui change pour la suite
Le cap des 200 outils ne signifie pas « objectif atteint ». Il change plutôt la question de priorité.
Avant d’ajouter une nouvelle famille, il devient utile d’examiner :
- ce qui manque réellement dans les catégories existantes ;
- quelles transformations renforcent plusieurs workflows ;
- quels moteurs peuvent être partagés ;
- quels outils méritent un widget ;
- quels parcours doivent être expliqués par un guide ;
- quelles opérations doivent rester de simples calculateurs autonomes.
Bethemesh peut être découvert comme une collection d’outils gratuits. C’est volontaire : l’entrée doit rester simple.
Mais l’architecture vise une continuité plus large :
outil → widget ou Workspace → pipeline réutilisable → guide pour comprendre le workflow
Le passage des 200 outils rend cette continuité plus importante que le compteur lui-même.
Pour découvrir cette organisation, commencez par Découvrir Bethemesh : outils, Workspace et pipelines, puis testez le Workspace sur une tâche qui nécessite réellement plusieurs étapes.
