On ne quitte pas un outil qu'on maîtrise par goût du changement. On le quitte le jour où le compromis qui nous convenait parfaitement ne nous convient plus.
Pendant des années,
WordPress a été la bonne réponse
Autant commencer par là, sinon la suite serait malhonnête : WordPress nous a servis pendant des années, Shopify aussi. On connaissait les outils, on savait travailler vite avec, on avait nos habitudes, nos extensions, nos méthodes et nos thèmes enfants.
Surtout, ils permettaient de proposer des sites complets à des tarifs qui restaient cohérents pour nos clients. À ce moment-là, ça fonctionnait.
Puis notre façon de construire a évolué, et les besoins avec. Les boutiques sont devenues plus complexes, les attentes en matière de vitesse ont augmenté, les outils se sont empilés, et nous avons commencé à passer de plus en plus de temps à optimiser, surveiller et maintenir quelque chose qui était justement censé nous en faire gagner.
Pourquoi est-ce que l'outil qui gère les contenus d'un site devrait aussi décider de son apparence ?
L'équation d'une agence n'est jamais seulement technique
Quand on construit des sites pour des clients, la technique n'est pas la seule contrainte : il faut aussi tenir un budget. On peut évidemment développer beaucoup de choses sur mesure, construire ses propres assets, écrire un thème enfant très propre, limiter les extensions et verrouiller ce que le client peut modifier. Dans ces conditions, oui, WordPress peut être très performant. Mais ce n'est plus tout à fait le même projet, ni le même prix.
À partir du moment où l'on construit une boutique, où l'on utilise un constructeur de pages comme Divi ou Elementor, où l'on ajoute des fonctions métier, des moyens de paiement, du référencement, des formulaires ou des comptes clients, la situation change : le site devient un assemblage.
Et cet assemblage est exactement ce qui permet de rester compétitif sur les prix, puisqu'on ne recode pas un panier, un système de paiement et une gestion de commandes à chaque client. C'est toute la force de WordPress. C'est aussi là que nous avons commencé à toucher nos propres limites.
Nous n'avons jamais réussi
à le rendre aussi rapide que nous le voulions
Autant le formuler comme ça, parce qu'il serait idiot de prétendre que personne n'est capable de faire un WordPress extrêmement rapide. Certains le font très bien. Nous, non.
Ou plutôt : pas dans les conditions où nous devions réellement travailler. Sur la centaine de sites que nous avons réalisés en un peu plus de dix ans, nous avons optimisé, mis en cache, allégé, supprimé des scripts, compressé des images, changé des extensions, repris du CSS, déplacé des chargements et testé différents hébergements. On obtenait de bons résultats, parfois de très bons résultats.
Mais nous n'avons jamais eu avec WordPress la sensation que nous avons aujourd'hui sur certaines façades Sillon : charger exactement ce dont la page a besoin, et à peu près rien de plus.
Ce que ça donne, et ce que ça ne garantit pas
La page d'accueil de ce site, mesurée sur PageSpeed Insights le 29 août 2026 : 100 sur mobile, et entre 97 et 99 sur ordinateur selon les passages. Ce n'est pas une page blanche avec trois lignes de texte, elle est animée.
Est-ce qu'un site Sillon fera toujours 100 ? Évidemment non. Une image mal préparée, une police lourde, vingt scripts externes ou une animation absurde peuvent parfaitement ruiner les performances, et aucune architecture ne protège de ça. Le score de performances sur ordinateur a d'ailleurs donné 97 puis 99 à une minute d'écart : c'est la mesure qui varie, pas le site.
Mais pour la première fois dans notre manière de travailler, nous atteignons régulièrement un niveau que nous n'avions jamais obtenu sur nos WordPress réels, ceux que nous pouvions effectivement vendre à nos clients dans des budgets raisonnables. Alors peut-être que nous étions simplement mauvais pour optimiser WordPress, c'est possible. Après une centaine de sites, on finit aussi par accepter qu'un outil ne corresponde plus à la façon dont on veut travailler.
L'IA a changé une partie du calcul
Pendant longtemps, la réponse semblait évidente : pour libérer complètement la façade, il faut développer davantage. Or développer davantage coûte du temps, donc de l'argent. C'était le verrou.
Puis les outils capables d'écrire, de reprendre et de modifier du code sont devenus réellement utilisables dans notre travail quotidien. Pas parce que l'IA allait construire des sites toute seule pendant qu'on buvait un café, mais parce qu'elle faisait disparaître une partie du coût qui nous obligeait jusque-là à accepter certains compromis.
Écrire une façade complètement indépendante devenait réaliste économiquement. Sur le papier, c'était formidable. Dans la pratique, on venait juste de déplacer le problème.
Une façade libre, c'est bien. Encore faut-il gérer ce qu'il y a derrière
Pour un petit site vitrine, on peut parfaitement se passer de back-office : quelques fichiers, du HTML, du CSS, éventuellement un peu de JavaScript, et le site fonctionne très bien. Le problème apparaît le jour où le client veut modifier quelque chose. Changer ses horaires, ajouter une réalisation, remplacer une photo. Sans système d'administration, quelqu'un doit remettre les mains dans le code.
Sur un site vitrine qui bouge deux fois par an, ce n'est pas forcément dramatique. Sur une boutique, ça devient tout de suite une autre histoire : il faut gérer les produits, les prix, les variantes, les stocks, les commandes, les clients, les paiements, les documents, parfois la TVA, les statuts, les emails et les droits d'accès. Développer « un petit back-office maison » n'a alors plus rien de petit.
Il faut être rigoureux, penser aux droits, aux erreurs, à la sécurité, à la structure des données, aux cas particuliers et à tout ce qui n'est absolument pas visible depuis la façade. Et surtout, il faut recommencer au projet suivant. Nous avions donc résolu notre problème de front, et nous venions de recréer exactement celui que WordPress nous évitait depuis des années.
Le back-office sait ce que la donnée est. La façade décide de ce qu'elle devient.
C'est là que Sillon a pris sa forme
Petit à petit, le besoin s'est clarifié. Nous ne voulions pas d'un outil qui construise les pages, et nous ne voulions pas non plus reconstruire un système d'administration pour chaque projet. Nous voulions un moteur commun, capable de gérer ce qui revient constamment d'un site à l'autre, et qui laisse complètement tranquille la partie visible.
D'un côté Sillon : les articles, les produits, les commandes, les clients, les médias, le référencement, les comptes et les modules activés pour le projet. De l'autre le site : son HTML, son CSS, son JavaScript, ses animations, son responsive et son identité. Entre les deux, les prises.
Les prises ne dessinent rien
C'est le point le plus important. Une prise ne dit pas « ce produit doit apparaître dans une carte blanche de 340 pixels avec une image au-dessus et un bouton orange en dessous ». Elle transmet ce dont la façade a besoin : le produit, son nom, son prix, ses images, ses informations, sa disponibilité.
Ensuite, le site fait ce qu'il veut avec. Une boutique peut afficher les mêmes données dans une grille très sage ou dans une interface totalement expérimentale, Sillon s'en moque. Et c'est précisément ce qu'on voulait.
Le client, lui, n'a pas besoin de savoir comment tout ça fonctionne
Il veut changer un prix sans se demander s'il va casser une colonne. Il veut remplacer une photo sans découvrir au passage comment fonctionne le responsive. Il veut publier une actualité sans comprendre pourquoi son titre a 48 pixels de marge sur mobile.Ce choix a aussi un prix
Séparer les deux n'est pas une solution magique : il faut construire la façade. Sillon ne fournit pas de constructeur de pages dans lequel on choisit un en-tête, trois colonnes et une galerie avant de cliquer sur « Publier ». Pour quelqu'un qui veut fabriquer lui-même son premier site sans coder, sans développeur et sans outil capable de générer son front, ce n'est pas la réponse la plus simple.
Et c'est très bien comme ça. Nous ne cherchons pas à supprimer tous les compromis, nous avons simplement choisi ceux que nous préférions.
Il reste un coût, évidemment : la licence, l'hébergement, et la création de la façade. Les modules disponibles sont inclus dans la licence, nous ne les vendons pas un par un ; le détail est sur la page des tarifs. C'est justement notre manière de travailler aujourd'hui qui change l'équation : en réutilisant des bases existantes, en construisant nos propres layouts et en nous faisant assister dans le code, nous gardons cette liberté sans revenir au prix d'un développement entièrement sur mesure à chaque projet. Le but n'était pas de supprimer le coût, mais de décider où nous acceptons de le payer.
Au fond, on n'a jamais vraiment voulu remplacer WordPress
C'est peut-être la partie la plus importante. Nous n'avons pas commencé Sillon avec l'idée de faire mieux que WordPress. Il nous a servis pendant des années, il nous a permis de construire énormément de sites et de proposer des projets que nous n'aurions pas pu vendre au même prix autrement, et il reste une excellente réponse pour beaucoup de situations.
Simplement, notre façon de travailler a changé, et un jour le compromis qui nous convenait parfaitement ne nous convenait plus. On passait trop de temps à surveiller l'outil, à contourner certaines contraintes et à optimiser ce que nous aurions préféré ne pas charger du tout.
Alors on a fini par se poser une question beaucoup plus simple : si le client a besoin d'un back-office et que le développeur a besoin d'une façade libre, pourquoi continuer à demander au même outil de faire les deux ? Sillon est né en grande partie de là.