Notre philosophie

Caputchin est bâti sur une seule posture, vue de trois côtés : nous sommes permissifs sur ce que tu peux faire, ouverts sur comment nous le faisons, et minimaux sur ce que nous gardons. Nous gâtons l'expérience gérée et la portée d'un changement, jamais la capacité brute, et nous ne retenons rien sur tes visiteurs parce qu'il n'y a rien dont nous ayons besoin.

Cette page expose cette posture. La personnalisation est là où tu la ressens le plus directement, donc elle mène, mais la même conviction parcourt notre façon de tarifer, ce que nous mettons en open source, et ce que nous refusons de collecter.

Le principe

Nous gâtons l'expérience du tableau de bord et la portée d'un changement. Nous ne gâtons pas la capacité brute.

Deux questions décident de quel côté de la ligne tombe une personnalisation :

Si tu la rédiges sur ta propre page, elle est à toi gratuitement. Si tu demandes à Caputchin de la rédiger pour toi et de la servir à chaque embed, c'est l'expérience payante.

Ce que chaque offre peut faire sur sa propre page

Celles-ci sont ouvertes à toutes les offres, y compris Solo, parce qu'elles vivent sur ta page, pas dans notre tableau de bord. Rien ici ne vérifie ton niveau.

• Recolorer tout le widget. Le shell expose ses couleurs comme propriétés CSS personnalisées que tu peux surcharger depuis ta propre feuille de style. Vois Styliser le widget avec CSS.
• Restyliser, redisposer ou masquer n'importe quelle part, y compris notre marque. Le widget se rend dans une racine shadow ouverte et expose ses pièces structurelles comme parts CSS, donc tu peux les cibler et les restyliser, ou masquer le bloc de marque entièrement. Aussi couvert dans Styliser le widget avec CSS.
• Rédiger à la main un skin et une locale de jeu personnalisés par embed. Sur l'élément <caputchin-game>, tu peux passer un objet skin ou locale en ligne pour surcharger les couleurs, ressources et chaînes de ce seul embed. C'est une propriété de ton propre balisage, donc ça fonctionne sur n'importe quelle offre. Vois Skiner un jeu et Personnaliser la langue d'un jeu.
• Choisir la langue et le thème. Les attributs locale et skin sélectionnent n'importe quelle langue embarquée ou thème clair et sombre. Vois Comment le widget résout sa langue et son skin.

La racine shadow ouverte est un choix délibéré, pas un oubli. Elle existe pour que cette surface CSS fonctionne. Nous n'allons pas la fermer pour protéger un paywall, parce que ça casserait une fonctionnalité documentée pour les développeurs que nous essayons de servir.

Ce qu'ajoutent les niveaux payants

Le chemin du tableau de bord est la même capacité, rendue gérée et dotée de portée. Voici ce qu'un niveau achète :

• Rédiger une fois dans le tableau de bord, servir à chaque embed. Un changement que tu fais dans le tableau de bord se propage à chaque montage de widget sur chaque page et clé de site, sans CSS par page à copier et à maintenir synchronisé. Le chemin gratuit est par page et manuel par nature.
• Portée d'équipe et par site. La personnalisation du tableau de bord se résout avec une base d'équipe et des surcharges par clé de site, donc une équipe peut fixer une marque une fois et surcharger les exceptions par clé. Une feuille de style n'a aucune notion de cette portée.
• Atteindre des surfaces que ton CSS ne peut pas. La page d'embed hébergée que les apps natives chargent dans une WebView est servie par Caputchin, donc tu ne possèdes aucun CSS ni JavaScript dessus. Un préréglage rédigé dans le tableau de bord est le seul moyen de marquer cette surface. Vois Intégration dans les apps mobiles.
• Faire ce qu'une page ne peut véritablement pas. Réécrire la formulation du shell, repointer les liens de sa bande de marque et échanger son logo proprement ne sont pas atteignables depuis une feuille de style du tout. Ce sont les véritables exclusivités de la mise en marque blanche du widget.

Quel axe se situe à quel niveau (configuration de jeu, langue et skin de jeu, et shell du widget) est résumé dans la table des niveaux de personnalisation des jeux, avec le shell du widget, notre échelon supérieur, couvert dans marque blanche.

Pourquoi nous traçons la ligne ici

Le partage garde deux publics contents à la fois sans compromettre ni l'un ni l'autre.

Un développeur avancé n'est jamais bloqué. Tout ce qu'il peut exprimer en CSS ou dans son propre balisage est à lui immédiatement, sur l'offre gratuite, donc le produit ne gêne pas quelqu'un qui sait ce qu'il veut. Une équipe qui achète un niveau payant paie pour la partie qui est réellement dure à bien faire à la main : rédiger en un seul endroit, la gouverner sur beaucoup de sites, la garder synchronisée, et atteindre des surfaces qu'elle ne contrôle pas. C'est une valeur réelle et continue, et il est honnête de la facturer.

Cela signifie aussi que nous n'avons jamais à combattre nos propres clients. Nous n'avons pas besoin d'anti-altération, d'une racine shadow fermée, ni d'une politique qui interdit d'utiliser la surface de stylisation que nous documentons, parce que nous ne prétendons pas qu'une capacité gratuite est payante. La capacité est gratuite. La commodité et la portée sont le produit.

La marque blanche est le sommet de l'échelle, pas un mur

La marque blanche est souvent lue comme la fonctionnalité qui te laisse enfin retirer notre marque. Ce n'est pas le cas. Tu pouvais déjà masquer notre marque gratuitement avec une règle CSS. La marque blanche est l'échelon supérieur de la même échelle sur laquelle se trouve chaque autre personnalisation : la version rédigée dans le tableau de bord, servie partout, plus les quelques choses qu'une page ne peut pas faire seule, à savoir réécrire la formulation, repointer les liens, échanger le logo proprement, et couvrir la page d'embed hébergée que les apps natives chargent dans une WebView. C'est plus de portée et moins de travail, pas une barrière autour de quelque chose qui t'était autrement refusé.

Ouvert par défaut, jusqu'au bout

La permissivité de cette page n'est pas une posture marketing. Elle est structurelle : le widget et le SDK que tu intègres sont open source, sous licence Apache-2.0, et développés à l'air libre sur GitHub. Tu peux lire chaque ligne du code qui tourne sur les pages de tes visiteurs, le forker, l'auditer, et ouvrir une issue ou une pull request contre lui. Nos jeux maison sont open source aussi.

Nous faisons ça pour deux raisons. D'abord, nous n'avons rien à cacher. Un widget de vérification qui demande la confiance de tes visiteurs devrait être inspectable, pas une boîte noire. Ensuite, les développeurs qui poussent la surface de personnalisation à ses limites sont exactement les gens dont nous apprenons. Étirer la surface CSS, rédiger à la main un skin de jeu, ou bâtir contre le contrat du SDK : quand ça fait surgir un bord rugueux ou un point d'accroche manquant, le correctif peut nous revenir directement comme contribution. Nous récompensons les utilisateurs avancés par une flexibilité maximale, et nous les accueillons comme contributeurs au code lui-même.

• Les paquets du widget et du SDK : github.com/Caputchin/caputchin-sdk.
• Les jeux maison, le Caputchin Core Pack : github.com/Caputchin/games.

Minimal par défaut

Le même instinct qui nous rend ouverts nous rend minimaux : nous gardons ce dont nous avons besoin et rien de plus. Nous ne collectons aucune donnée sur les personnes qui résolvent tes épreuves. Pas d'IP, pas de User-Agent, pas d'empreinte, pas de télémétrie comportementale. C'est architectural, pas une promesse de politique, parce que le protocole du widget n'a nulle part où mettre un identifiant de visiteur, donc il n'y en a aucun à laisser fuiter, à assigner ou à vendre. Le jeu atteint la même fin sans profiler personne : il re-dérive si une manche a réellement été réussie plutôt que de deviner à partir des trajectoires de souris et du timing des taps, ce qui est la posture anti-triche du jeu.

Pour toi, le client, nous gardons le minimum dont un compte a besoin : ton e-mail, la configuration de ta clé de site, et un journal d'audit de tes propres actions. La suppression est dure, sans soft-delete gardant une copie discrète. La posture complète est dans notre Politique de confidentialité, et la même règle sans-donnée-visiteur se poursuit dans la vérification hébergée.

Permissif, ouvert et minimal sont une seule conviction sous trois angles : nous te donnons le plus de contrôle que nous pouvons, nous te montrons exactement comment ça marche, et nous demandons le moins que nous pouvons en retour.

Voir aussi

• Styliser le widget avec CSS : la surface de stylisation gratuite, les parts et les variables de couleur.
• Marque blanche du widget : la version rédigée dans le tableau de bord, servie partout, et les choses que seule elle peut faire.
• Personnalise les jeux auxquels jouent tes visiteurs : la personnalisation par axe et le niveau d'offre où chacune atterrit.
• Politique de confidentialité : la posture sans-donnée-visiteur en entier.