Pourquoi Fóir existe
Huit ans passés à construire des logiciels pour d'autres, et la même lacune dans presque tous les projets. Un système de gestion de contenu vous mène presque au bout. La partie qu'il ne couvre pas est celle où part le budget.
Tout a commencé par du travail pour des clients
Fóir est né d'un studio qui livre des logiciels pour des clients. Les produits différaient d'un projet à l'autre. En dessous, chacun avait besoin des mêmes éléments : du contenu qu'un éditeur pouvait modifier sans développeur, des données appartenant à certains utilisateurs, la connexion, le stockage de fichiers, des tâches planifiées et des règles sur qui avait le droit de voir quoi.
Nous avons construit ces éléments projet après projet, et chacun nous a appris quelque chose sur la façon dont ils devaient s'assembler. Après assez de projets, les motifs ont cessé de changer, et cela avait de moins en moins de sens de les reconstruire pour chaque client.
Les derniers dix pour cent
Un CMS prêt à l'emploi répond presque au cahier des charges. Vient ensuite la partie qu'il n'allait jamais couvrir : l'espace connecté, le contenu qui diffère selon le client, le workflow qui va chercher dans un autre système.
À ce stade, il y a trois voies, et chacune coûte. Exploiter deux systèmes et écrire l'intégration entre eux. Construire le backend et y greffer un CMS tiers sur le côté. Ou construire le backend et reconstruire les outils d'édition que votre équipe savait déjà utiliser. Nous avons chiffré les trois plus d'une fois, et aucune n'est ce que quelqu'un voulait acheter.
Un agent le reconstruit à chaque fois
Un développement moins cher aurait dû rendre cette dernière partie abordable. Il l'a rendue fréquente. Un agent à qui l'on demande de construire une application assemble les mêmes pièces manquantes à chaque projet : connexion, base de données, stockage de fichiers, permissions, file de tâches. La plupart sont critiques pour la sécurité, et vous faites confiance au fait qu'il a correctement assemblé chacune, à chaque fois, dans une base de code que personne n'a lue de bout en bout.
Avec Fóir, ces pièces arrivent déjà assemblées, et nous les exploitons. L'agent écrit ce qui est propre à votre produit, sur un backend dont il n'a aucun moyen d'omettre les règles d'accès.
Les bugs de ce code sont des absences
Les défaillances d'un backend assemblé sont discrètes : une vérification sur un chemin que personne n'a exercé, une requête à laquelle il manque une clause, une clé qui porte plus loin que la personne qui la détient.
On ne peut pas arriver à la confiance en relisant quelque chose qui n'est pas là. Ce qui fonctionne, c'est un système où la vérification ne peut pas être omise. Dans Fóir, les règles d'accès se compilent dans la sécurité au niveau des lignes de la base de données elle-même : une requête qui oublie une vérification ne renvoie que ce que son appelant a le droit de voir, et une nouvelle table fait échouer nos tests tant que personne n'a décidé comment elle est protégée. Le moteur qui fait cette compilation est Demesne, et il est open source.
Nous construisons dessus nous-mêmes
Fóir est la fondation à partir de laquelle nous démarrons notre propre travail. Ce site fonctionne dessus, et c'est là que partent nos nouveaux projets clients. Les décisions que nous reprenions à chaque construction, comme la façon de modéliser le contenu et de garder les données d'un utilisateur à lui, sont prises une fois pour toutes.
Un backend doit être exploité autant qu'écrit : Fóir est donc un service géré. La partie qui décide qui peut voir vos données est publiée pour que tout le monde puisse la lire.
Nous avons donc construit celui pour lequel nous continuions à faire des devis
Chaque projet a payé pour reconstruire la même fondation.
Fóir est cette fondation, exploitée pour vous : contenu structuré et données applicatives dans un seul runtime, avec connexion hébergée, médias, personnalisation, automatisation et une API générée déjà reliés entre eux. Vous commencez directement par votre propre logique métier.
Ce qu'il remplace
Les abonnements et les chantiers de développement qu'il remplace, au même endroit et sur une seule facture.
Un CMS headless
L'interface éditoriale, le schéma, les brouillons et l'historique des versions.
Un fournisseur d'authentification
La connexion de vos propres utilisateurs, sur votre propre domaine, avec les rôles qui vont avec.
Du stockage et un CDN
Les téléversements, les transformations d'images, la diffusion vidéo et la distribution qui les précède.
Un service de recherche
Du plein texte sur vos enregistrements, et des vecteurs pour retrouver par le sens.
Un exécuteur de tâches
Des planifications, des opérations en arrière-plan, des relances et un endroit où envoyer les échecs.
Un fournisseur de messagerie
E-mail transactionnel, in-app et push, avec des préférences conservées par client.
La couche d'intégration
Le code qui tiendrait autrement ces six éléments ensemble, et la dérive entre eux.
Les personnes qui appliquent les correctifs
Aucun de vos serveurs n'est à tenir à jour, et il n'y a pas de week-end de mise à niveau.
Voir si cela tient la route
Chaque capacité, et les comparaisons où nous disons clairement quel outil nous choisirions à la place.