Toornament est la référence par défaut de l'esport européen, et ce n'est pas un hasard. Le produit fait tourner des compétitions depuis des années, couvre des centaines de jeux et tous les formats courants, et la plupart des organisateurs européens s'en sont servis au moins une fois. Si vous lisez cette page, il y a de bonnes chances qu'il soit déjà ouvert dans un autre onglet.
Toornament propose aussi un véritable produit white-label, et il faut le dire clairement, car la plupart des pages de comparaison font semblant du contraire. Leur plateforme white-label tourne sur votre nom de domaine avec son propre hébergement et sa propre base de données, gère la création de comptes, l'authentification tierce, les profils, les équipes, les inscriptions, la remontée des résultats et l'archivage, et s'édite via un builder no-code. Leur propre description est sans ambiguïté : vous contrôlez l'administration, le modèle et le branding, et vous possédez le contenu généré.
Le cadrage honnête n'est donc pas white-label contre non-white-label. Les deux produits posent une compétition sur votre domaine, à votre nom. La différence est dans le chemin pour y arriver, et dans ce que vous pouvez faire ensuite.
Configurer ou construire
La plateforme white-label de Toornament est un produit fini que vous configurez. Il y a une interface de construction, et dans les limites de ce qu'elle expose, vous pouvez faire beaucoup sans écrire une ligne de code. Tanitar a l'autre forme : une API, plus des templates de front-end que vous forkez et dont vous possédez le code source. Vous partez d'une application qui fonctionne plutôt que d'une page blanche, mais c'est votre dépôt dès le premier commit.
| Configurer une plateforme | Construire sur une infrastructure | |
|---|---|---|
| Comment vous la modifiez | Une interface de configuration | Votre code, contre l'API |
| Plafond | Ce que le builder expose | Ce que vous savez écrire |
| Front-end | Le leur, thémé et hébergé par eux | Le vôtre, forké d'un template |
| Qui l'exploite | Eux, en grande partie | Vous, ou eux si vous préférez |
| Délai de lancement | Selon le projet et l'accompagnement | 48 heures depuis un template |
| Ingénierie nécessaire | Aucune pour démarrer | Un peu, et c'est un vrai coût |
Aucune des deux colonnes n'est meilleure dans l'absolu. Elles répondent à des questions différentes, et celle qui les sépare est : que se passe-t-il au quatrième mois, quand quelqu'un demande une fonctionnalité que personne n'avait prévue ?
Quand Toornament est la meilleure réponse
- Vous voulez un projet géré, avec design, mise en place de l'hébergement et opérations de tournoi pris en charge — Toornament vend des services avec la plateforme, ce qui est réellement utile sans équipe interne.
- Vous n'avez aucune ressource d'ingénierie et aucune intention d'en recruter.
- Vos besoins sont bien couverts par un builder no-code, et vous préférez ne pas posséder de code du tout.
- Vous voulez la garantie d'un produit qui fait tourner de grandes compétitions depuis des années, y compris pour des éditeurs majeurs.
Si cela vous décrit, prenez Toornament. Une recommandation n'a de valeur que si elle peut pencher dans l'autre sens.
Quand l'infrastructure est la meilleure réponse
- La compétition doit être une fonctionnalité dans un produit plus large — l'application d'un opérateur télécom, un portail universitaire, le site d'une campagne — plutôt qu'une destination à part entière.
- Vous avez besoin de plusieurs environnements isolés et brandés séparément dans un seul contrat, pas d'une plateforme par marque.
- Les données d'inscription et de match doivent être dans vos systèmes en temps réel, pas exportées après coup.
- Vous comptez étendre le produit plutôt que demander des fonctionnalités, et vous voulez que la roadmap soit la vôtre.
- L'arabe compte. Un right-to-left conçu dès l'origine plutôt que rajouté après donne une autre expérience, et c'est la raison la plus fréquente d'arriver sur cette page depuis le Moyen-Orient et l'Afrique du Nord.
La question de l'API
Toornament expose une API, située sur les offres hautes : accès basique sur leur palier public le plus élevé, accès complet dans un projet sur mesure. C'est une façon raisonnable de facturer une plateforme, et cela dit quelque chose du modèle : l'API est un complément au produit, et le produit c'est l'interface.
Chez Tanitar, c'est l'inverse. L'API est le produit ; les templates sont un confort pour ne pas partir de zéro. Tous les paliers appellent les mêmes endpoints, car il n'y a rien en dessous dont ils pourraient être le complément.
Un moyen pratique de trancher : imaginez la troisième chose que vous voudrez et qui n'est aujourd'hui sur la liste de fonctionnalités de personne. Si vous vous voyez la déposer comme demande, configurez. Si vous préférez l'écrire un mardi, construisez.
Ce que les tableaux comparatifs ne diront pas
Les grilles de fonctionnalités rendent ces produits presque identiques, parce qu'au niveau des brackets et des inscriptions, ils le sont. Les deux font l'élimination simple et double, le suisse, le round robin et les poules. Les deux gèrent inscriptions, seeding et résultats. En débattre n'est pas un bon usage d'une évaluation.
Les questions qui décident vraiment portent sur la propriété et la portée. À qui appartient le code. Où vivent les données pendant que la compétition tourne. Que se passe-t-il à la fin du contrat. Combien d'environnements brandés séparément pouvez-vous faire tourner, et combien coûte le deuxième. La plateforme doit-elle fonctionner dans une langue que l'équipe qui écrit la roadmap ne lit pas.
Le résumé honnête
Toornament est un produit mature et crédible, avec une vraie offre white-label et une équipe de services derrière. Si vous voulez une plateforme de compétition prise en charge pour vous, c'est une bonne réponse, et ça l'est depuis des années.
Tanitar s'adresse au cas où la compétition est une infrastructure à l'intérieur d'autre chose que vous construisez, où vous voulez le code source plutôt que les réglages, et où l'arabe ou le français est une exigence plutôt qu'une passe de traduction. Si c'est le brief, une plateforme configurée s'en approchera puis s'arrêtera à la limite du builder.