La plupart des agences considèrent leurs outils internes comme un secret de fabrication. Nous faisons l’inverse : tout ce que nous utilisons pour gérer nos 120+ sites WordPress est publié en accès libre, sur GitHub, lisible et téléchargeable par n’importe qui. Voici pourquoi cette transparence vous protège, ce qu’elle nous coûte, et ce qu’elle nous rapporte.
La pratique standard dans les agences digitales
Dans le métier d’agence digitale, les outils internes sont traditionnellement gardés secrets. Les scripts de déploiement, les automatisations de maintenance, les modules d’extension du CMS, les processus de sécurité : tout cela reste dans les coulisses, présenté au client comme « notre méthode propriétaire ».
L’argument commercial est compréhensible. Si vous racontez tout, vos concurrents peuvent vous copier. Si vous publiez votre code, vos clients pourraient théoriquement le récupérer et se passer de vous. Si vous documentez vos méthodes, vous facilitez la vie des entreprises qui voudraient internaliser ce que vous faisiez.
C’est la logique défensive du métier depuis vingt ans. Et c’est aussi, à notre avis, une logique qui dessert le client autant que l’agence.
Le problème invisible du « secret de fabrication »
Quand vous travaillez avec une agence dont les outils sont opaques, vous prenez trois risques sans toujours les voir.
Le risque de dépendance excessive. Si quelque chose tourne mal — votre agence ferme, vous changez de prestataire, vous voulez internaliser — vous découvrez que personne ne peut reprendre la maintenance, parce que personne ne sait comment les outils sont construits. Vous êtes captif. C’est ce qu’on appelle le « vendor lock-in » et c’est l’un des problèmes les plus coûteux pour une PME qui veut grandir.
Le risque de qualité non vérifiable. Quand une agence vous dit « nous avons une chaîne de sécurité solide » ou « nos sauvegardes sont infaillibles », vous n’avez aucun moyen de le vérifier. Vous croyez sur parole. Si ça se révèle faux le jour où vous en avez besoin, il est trop tard.
Le risque de stagnation. Une équipe qui code en vase clos, sans regards extérieurs, accumule des erreurs qu’elle ne voit plus. Les outils tournent en rond, parfois pendant des années, avec des défauts que personne ne signale parce que personne d’autre que l’équipe ne les voit.
Notre choix : tout est sur la table
Quand nous avons commencé à structurer nos outils internes en 2024, nous avons fait un choix qui a surpris notre conseil : tout ce qui pouvait être public le serait. Pas seulement la « vitrine » — l’ensemble du code de production.
Voilà, en pratique : ce qui est aujourd’hui en accès libre :
- Le code complet du système qui sécurise les modifications sur nos sites WordPress (sauvegarde automatique, validation, restauration en un clic)
- Les modules d’extension pour les CRM que nous installons chez nos clients
- Les outils d’audit et de monitoring de notre infrastructure d’hébergement
- Les scripts de déploiement, les procédures de sauvegarde, les checklists de mise en ligne
- Les méthodes documentées que nous appliquons sur chaque chantier
Tout cela est disponible sur GitHub, sous licence libre, téléchargeable et utilisable par n’importe qui. Y compris nos concurrents. Y compris vos prochains prestataires si vous décidez un jour de changer.
Ce que cette transparence vous garantit
Du côté client, ce choix se traduit par cinq garanties concrètes.
Vérification indépendante. Si nous écrivons que « nos sauvegardes sont automatiques, validées et restaurables en moins de dix secondes », vous pouvez demander à n’importe quel développeur tiers de vérifier le code. C’est dans le repository public, c’est lisible, c’est testable. La vérification ne dépend pas de notre bonne foi.
Continuité opérationnelle. Si nous fermons demain — ce qu’on ne souhaite pas, mais qui peut arriver — vos sites continuent à fonctionner avec les outils déjà en place, et n’importe quel prestataire peut reprendre la maintenance en lisant le code. Vous n’êtes jamais bloqué.
Pas de coûts cachés. Quand un outil interne propriétaire évolue, l’agence vous facture la mise à jour parce que vous n’avez pas d’autre choix que de payer pour rester compatible. Avec un outil open source, les évolutions sont publiques, leur impact est documenté, et vous pouvez décider en connaissance de cause.
Recrutement facilité côté prestataire. Les développeurs qui rejoignent notre équipe peuvent étudier nos méthodes avant même le premier entretien. Ils arrivent productifs en quelques jours plutôt qu’en quelques semaines. Vous bénéficiez d’une équipe qui n’a pas besoin de se former à des outils maison obscurs.
Réputation vérifiable. Quand nous écrivons un article de retour d’expérience comme celui-ci, vous pouvez vérifier que les outils mentionnés existent, fonctionnent comme décrit, et sont utilisés en production. Pas de slides marketing creux.
Ce que ça nous coûte
Cette transparence n’est pas gratuite pour nous. Voici ce qu’on en paye.
Du temps de documentation. Publier du code utilisable par d’autres demande une documentation soignée. Compter environ 20 % de temps de travail supplémentaire sur chaque outil publié, par rapport à un outil simplement utilisé en interne. C’est du temps réel, qu’on a choisi d’investir.
Une exposition aux regards critiques. Quand notre code est public, les défauts sont visibles. Il nous est arrivé d’être contactés par des développeurs externes signalant des bugs ou des vulnérabilités dans nos outils. C’est désagréable sur le moment et précieux à long terme : nous corrigeons des problèmes que nous n’aurions jamais vus seuls.
Une difficulté commerciale ponctuelle. Certains clients potentiels nous ont demandé « pourquoi je vous paierais si tout est en libre accès ». La réponse est dans cet article : la valeur d’une agence n’est pas dans le code, elle est dans l’expérience, la responsabilité opérationnelle et la capacité d’intervention. Mais cette pédagogie commerciale prend du temps.
Ce que ça nous rapporte
Et ce que ça nous rapporte, parce que rien n’est gratuit.
Une réputation qui se construit toute seule. Nos outils sont utilisés par d’autres agences en France, en Belgique et au Luxembourg. Chaque fois qu’un développeur les télécharge, lit la documentation et apprécie le travail, c’est une recommandation potentielle. Plusieurs de nos clients actuels sont arrivés par cette voie.
Un recrutement qui se fait à l’inverse. Les développeurs qui aiment notre manière de travailler nous contactent spontanément, parce qu’ils ont étudié notre code et qu’il leur plaît. Nous n’avons pas eu à publier d’offre d’emploi depuis deux ans.
Une discipline interne renforcée. Savoir que le code sera public oblige à écrire propre. C’est une motivation puissante. Notre équipe technique progresse plus vite parce qu’elle sait que son travail est exposé.
Une contribution à l’écosystème. Nous avons commencé avec WordPress, Elementor et Perfex CRM qui sont eux-mêmes open source. Contribuer en retour est une question d’éthique professionnelle, pas seulement de calcul commercial.
Comment vérifier vous-même
Si vous voulez voir concrètement ce que ça donne, vous pouvez visiter notre organisation GitHub. Vous y trouverez nos outils principaux, leur documentation, leur historique de modifications, et les retours de la communauté.
Vous n’avez pas besoin d’être développeur pour vérifier les choses essentielles : la régularité des mises à jour (un projet maintenu publie souvent), la qualité de la documentation (un projet sérieux explique comment ça marche), et la réactivité aux signalements (les vrais professionnels répondent quand on leur signale un problème).
Cinq questions qui reviennent dans les RDV
Si tout est libre, je peux récupérer le code et faire faire la maintenance par mon neveu, non ?
Techniquement, oui. Pratiquement, ça revient à demander à quelqu’un qui sait conduire de piloter un avion parce qu’il a le manuel. Le code est l’outil, pas la compétence. Ce que nous facturons, c’est l’expérience accumulée sur des centaines de cas, la capacité à intervenir vite quand quelque chose tourne mal, et la responsabilité opérationnelle d’avoir un site qui ne tombe pas.
Pourquoi vos concurrents ne font-ils pas la même chose ?
Probablement par peur de perdre leur avantage commercial, ou par habitude. Les pratiques évoluent doucement dans notre secteur. Et puis, soyons honnêtes, certains préfèrent que leurs clients ne puissent pas vérifier leurs prétentions techniques.
Mon site contient des données sensibles. Sont-elles dans le code public ?
Non, absolument pas. Seuls les outils sont publics. Vos données — articles, contacts, commandes, informations clients — restent strictement dans votre base de données et nos sauvegardes privées. La séparation est totale et auditée.
Est-ce que ça veut dire que mon site est moins sécurisé puisque les attaquants peuvent étudier vos outils ?
C’est l’inverse, en fait. C’est ce qu’on appelle le principe de Kerckhoffs en cryptographie depuis 1883 : un système est plus sûr quand ses mécanismes sont publics, parce qu’ils sont scrutés et testés par tout le monde. La sécurité repose sur la robustesse de la conception, pas sur le secret. Tous les outils de chiffrement modernes (HTTPS, WhatsApp, votre carte bancaire) fonctionnent sur ce principe.
Est-ce que ça veut dire que vous travaillez moins puisque le code existe déjà ?
Au contraire, nous travaillons mieux. L’effort n’est plus dans la réinvention permanente de la roue, mais dans l’adaptation précise à votre cas spécifique. Vous bénéficiez d’outils mûris par des années d’usage — la même rigueur qui nous permet aujourd’hui de livrer des sites trois fois plus vite avec Claude Code, ajustés à votre projet particulier.
Pour aller plus loin
Vous voulez comprendre comment nos méthodes pourraient s’appliquer à votre projet ? Nous proposons un échange initial de trente minutes pour discuter de votre besoin et identifier les outils pertinents.
Démarrer la conversation sur WhatsApp →
Notre code est publié sur github.com/Mogacode-ma et github.com/onimperium. Téléchargeable, lisible, modifiable.