Stratégie

Pourquoi je ne fais pas de levée de fonds, et pourquoi vous ne devriez probablement pas non plus.

La sagesse dominante des deux dernières décennies de la tech : levez tôt, grossissez vite, capturez le marché avant que quelqu’un d’autre ne le fasse. Cette grille est devenue tellement omniprésente qu’elle passe pour une vérité universelle. Elle n’en est pas une.

Pour qui cette grille est valide

Pour les entreprises qui ont un investisseur à satisfaire. Un investisseur, par définition, veut un retour multiplicateur — typiquement 10x à 100x sur 7-10 ans. Cette exigence impose une stratégie de croissance rapide pour atteindre la taille critique qui permet la sortie (acquisition ou IPO). C’est cohérent. C’est même mathématiquement nécessaire dans ce modèle.

Pour qui elle ne l’est pas

Pour les solos, les petites équipes, les artisans, les indépendants. Si vous n’avez pas d’investisseur, vous n’avez pas l’obligation de multiplier votre activité par dix. Vous avez l’obligation, beaucoup plus simple et beaucoup plus saine, de la rendre durable. C’est une grille radicalement différente.

Les implications concrètes

Si la mission est de durer (et pas de scaler), beaucoup de décisions deviennent évidentes :

• Choisir des technologies qui existeront encore dans dix ans. WordPress aura 20% du web en 2036. Probablement pas le SaaS hype du moment. Préférer WordPress.
• Bâtir sur des standards portables. Mon site peut être migré en un week-end vers un autre hébergeur. C’est inestimable.
• Garder une structure minimaliste. Pas d’équipe à motiver pendant les périodes de doute. Pas de bureaux à payer.
• Travailler à un rythme tenable. Trois à cinq heures de concentration par jour, sur quarante ans, c’est beaucoup d’œuvre construite. Dix heures par jour sur cinq ans avant burnout, beaucoup moins.

Le piège du “et si ça marchait vraiment ?”

Quand on commence à expliquer ce mode opératoire, on entend systématiquement la question : “Mais si demain ton concept cartonnait, tu ferais quoi ?” Comme si la seule possibilité de succès était l’explosion. La réponse honnête : si demain ça cartonnait, je ferais exactement la même chose, juste avec plus de marge de manœuvre. Je ne grossirais pas. Je ne recruterais pas. Je ferais durer plus longtemps.

Cette stabilité-là est un produit en soi. Beaucoup de clients préfèrent un prestataire qui sera là dans cinq ans (un solo) à un prestataire qui pourrait être racheté ou fermer dans dix-huit mois (une startup en croissance). La “scalabilité” est sur-vendue ; la pérennité est sous-évaluée.

Conclusion

Construire pour durer n’est pas un repli défensif. C’est une stratégie offensive, simplement orientée vers une autre forme de succès — celui qui se mesure en années d’activité maintenue, en autonomie préservée, en qualité de vie cumulée. C’est l’opposé exact de “grossir vite ou disparaître”. C’est, je crois, le mode opératoire qui devient à nouveau accessible et désirable à l’âge des LLM locaux.

Technique

Comment je déploie un mu-plugin sur neuf sites en une commande.

Git côté serveur, c’est lourd. Sur un hébergement mutualisé sans accès root, c’est carrément un problème. Voici l’alternative que j’utilise depuis 18 mois.

Le problème

Je dois modifier un mu-plugin (par exemple ajouter une règle de sécurité dans security-hardening.php) et le déployer sur mes neuf sites WordPress. Solution naïve : modifier sur le premier site via FTP, tester, puis répéter neuf fois. C’est tedious et source d’erreurs.

Le pattern DISPATCH

Un seul script bash en SSH qui :

1. Lit un fichier source (le mu-plugin modifié) depuis ~/upload-pack/
2. Itère sur une liste de sites (variable bash SITES=(seed patashop sleepwell ...))
3. Pour chaque site, copie le fichier dans son wp-content/mu-plugins/
4. Vérifie que la copie a bien eu lieu (taille, contenu)
5. Affiche un récap propre

Le tout en 30 lignes de bash. Pas de Git, pas de runners CI, pas de pipeline. Juste un script qui fait une chose et la fait bien.

L’exemple concret

#!/bin/bash
SOURCE=~/upload-pack/security-hardening.php
SITES=(seed patashop sleepwell bienetre40 shopbluedolomites tcbluedolomites maneuro yakapa bluedolomites)

for SITE in "${SITES[@]}"; do
    DEST="$HOME/$SITE/wp-content/mu-plugins/security-hardening.php"
    cp "$SOURCE" "$DEST"
    chmod 644 "$DEST"
    echo "✓ $SITE : déployé"
done

Pourquoi c’est suffisant

Pour mon cas d’usage (un seul opérateur, neuf sites, mu-plugins qui changent rarement), Git apporterait une complexité disproportionnée par rapport au bénéfice. Le coût de la complexité Git (branches, merges, rebases, conflits, runners CI) dépasse largement le bénéfice du versioning fin pour un déploiement qui se résume à “copier ce fichier sur N machines identiques”.

Le versioning, je le fais via les archives daily (~/_archives/2026-06-03/) — ce qui me donne un historique chronologique des fichiers sans complexité d’arborescence Git.

Quand utiliser autre chose

Si vous êtes plusieurs développeurs avec des changements concurrents, ou si vos sites ont des configurations vraiment divergentes, Git devient nécessaire. Mais pour un solo entrepreneur avec un portfolio uniforme, DISPATCH est radicalement plus simple et largement suffisant.

Technique

L’écart entre la commodité et la maîtrise.

Ollama est le projet le plus populaire pour faire tourner des LLM en local. Tous les tutos en parlent. Et pourtant, je n’en veux pas chez moi. Voici pourquoi.

Ce qu’Ollama résout bien

L’onboarding. Trois commandes et vous avez un Llama 3 qui tourne. Pour quelqu’un qui découvre les LLM locaux, c’est parfait. Pour quelqu’un qui veut juste essayer, idem.

Ce qu’Ollama abstrait trop

Le runtime exact. Ollama emballe llama.cpp dans une interface unifiée, mais cache les paramètres importants (taille du contexte, layers GPU, quantization choisie, threads CPU, prompt template). Le jour où votre modèle hallucine ou tourne trop lentement, vous ne savez pas par où commencer parce que ces paramètres sont gérés “pour vous”.

La gestion des modèles. Ollama télécharge les modèles dans un format propriétaire (.ollama) qui n’est pas un GGUF standard. Si demain vous voulez migrer vers llama.cpp direct, vLLM, ou un autre runtime, vos modèles téléchargés ne sont pas réutilisables tels quels.

Le serveur HTTP. Ollama expose un serveur sur le port 11434, ce qui crée une dépendance forte sur sa CLI et son API. Tout votre code applicatif appelle Ollama. Si vous voulez changer de runtime, il faut tout réécrire.

Mon choix : llama-cpp-python direct

J’utilise llama-cpp-python dans un environnement Python virtuel, qui charge directement un fichier GGUF récupéré de Hugging Face. C’est plus brut, plus exigeant à configurer au départ, mais :

• Je vois et je contrôle tous les paramètres (n_ctx, n_threads, n_gpu_layers, temperature, repeat_penalty, etc.)
• Mes modèles GGUF sont des fichiers standards, réutilisables avec d’autres runtimes
• Mon code applicatif appelle directement la fonction Python, pas un serveur HTTP intermédiaire
• Quand quelque chose ne fonctionne pas, je peux lire le code source du runtime sans abstraction Ollama-spécifique

Le principe sous-jacent

Cette décision illustre un principe plus large que j’applique partout : quand un outil abstrait quelque chose, il faut savoir ce qu’il abstrait et pouvoir s’en passer le jour où on en aura besoin. Ollama abstrait trop, et son écosystème vous lock-in à mesure que vous bâtissez du code par-dessus. Trois mois de développement basés sur Ollama, c’est trois mois de code à refaire si vous voulez migrer.

Ce n’est pas qu’Ollama est mauvais — c’est qu’il est mauvais pour mon cas d’usage (outil professionnel intégré dans un agent custom). Pour quelqu’un qui veut juste essayer un LLM local depuis une CLI, Ollama est probablement le bon choix.

Technique

Ce qui tient effectivement sur le bureau.

Tout l’arsenal technique tient sur une seule page. C’est volontaire.

Hébergement

IONOS shared hosting, environ 15 € par mois. PHP 8.3, MySQL 8, 10 GB de disque. Tous les sites sont des sous-dossiers d’un même compte FTP/SSH. Permet le partage des mu-plugins via lien symbolique ou copie scriptée.

CMS

WordPress 6.x + thème Storefront (officiel WooCommerce). Pour chaque site, un child theme minimal qui ne touche qu’à la couleur et à quelques classes utilitaires. Aucune personnalisation profonde du thème — Storefront est conçu pour ne pas avoir besoin d’être modifié.

Mu-plugins partagés

Sept mu-plugins déployés à l’identique sur les neuf sites :

• og-enhanced.php — OpenGraph meta tags propres pour le partage social
• security-hardening.php — durcissement (XML-RPC bloqué, désactivation enum users, etc.)
• hide-wordpress.php — masque /wp-admin et /wp-login.php, accès via /boutique-admin
• cached-translations.php — cache des traductions TranslatePress
• journalists-affiliate.php — bloc auteur + liens Amazon affiliés en fin d’articles
• site-categorization.php — taxonomies métier partagées
• trp-custom.php — overrides ciblés sur TranslatePress

Plugins officiels

Yoast SEO, WP Super Cache, Limit Login Attempts Reloaded, WP Mail SMTP. Stack identique sur les neuf sites, pas de surprise.

Agent IA local

AgentBMax, un mini-PC sous Windows 11 (8 GB de RAM, processeur Intel modeste) qui fait tourner un LLM en local via llama-cpp-python (modèle Qwen 2.5-3B-Instruct quantizé Q4_K_M). Tourne 24/7, surveille les sites, fait les sauvegardes la nuit, m’envoie un briefing matinal par mail, et m’assiste pour rédiger des articles via une interface web locale (FastAPI + HTML inline).

Outils de déploiement

WP-CLI (via php8.3-cli wp-cli.phar) pour scripter les mises à jour de contenu et de configuration. Bitwise SSH pour l’accès distant. FileZilla pour les uploads de fichiers PHP. Pas de Git côté serveur — le pattern DISPATCH (voir l’article dédié) suffit pour mes besoins.

Coût total

Environ 22 € par mois chez IONOS pour hébergement + DNS + mail pro, plus l’électricité du mini-PC à la maison (~5 € de consommation effective). Zéro abonnement SaaS. Achat unique du mini-PC à 600 € amorti en deux ans face à des SaaS équivalents.

Ce qui n’est pas là

Pas d’analytics SaaS (Plausible self-hosted si besoin). Pas de Slack (mail + Signal). Pas de Notion (markdown + un répertoire bien rangé). Pas de Zoom (Jitsi self-hosted ou téléphone). Pas de Google Workspace (mail IONOS, calendrier ICS local). C’est étonnant comme on peut tenir une activité sérieuse sans tout ça.

Pratique quotidienne

Pourquoi je passe une heure par jour en forêt, sans téléphone.

Ce n’est pas du bien-être commercialisé. C’est une discipline de travail.

Quand on passe sept heures par jour devant un écran, le cerveau s’organise autour de cette unité — la fenêtre rectangulaire, la lumière froide, le scroll infini, les décisions toutes les six secondes. Au bout de quelques années de ce régime, on perd la capacité de tenir une pensée longue. Tout est haché, fragmenté, divertissant. C’est l’opposé exact de ce qu’il faut pour un travail concentré.

L’expérimentation

En 2024, j’ai testé une discipline simple : une heure par jour en forêt, vraiment seul, vraiment sans téléphone (téléphone laissé à la maison, pas en poche). Ni musique, ni podcast. Juste marcher et regarder.

Les premières fois, c’est presque douloureux. On cherche son téléphone toutes les deux minutes, on sent l’absence de stimuli comme un vide. On a des pensées intrusives sur les mails non lus, les commandes à expédier, les choses qu’on aurait dû faire. Au bout d’une dizaine de minutes, ça se calme. Au bout de trente, c’est une autre forme de pensée qui revient — plus lente, plus continue, qui tient sur la durée et fabrique des liens entre des sujets éloignés.

Les résultats

Trois choses ont changé en quelques mois :

1. Les idées de stratégie viennent là, pas devant l’écran. Quasi systématiquement, les vraies décisions importantes (changer de stack, abandonner un projet, repositionner une marque) ont émergé en forêt, pas en travaillant.
2. Le travail concentré du matin est plus dense. Une heure de travail au calme après une heure de forêt vaut probablement trois heures de travail fragmenté à 16h.
3. Le rapport à l’attention change. On supporte de moins en moins les sollicitations inutiles. Les notifications push deviennent insupportables. On les coupe. La vie en redevient plus simple.

L’erreur à ne pas faire

Croire que c’est un luxe. C’est un investissement productif au sens littéral : une heure d’attention forêt aujourd’hui produit plusieurs heures de productivité supérieure demain. Le calcul est rentable.

Ne pas en faire un projet d’optimisation non plus. Pas de tracking, pas de comptage de pas, pas d’objectif de kilométrage. C’est précisément l’inverse de l’esprit recherché. On y va pour ne pas être quantifié. C’est tout.

Stack & méthode

Mon principe de tri.

Je ne suis pas anti-tech. Je suis pro-tech sélective. La différence est immense.

Voici le critère que j’applique à chaque outil avant de l’adopter : amplifie-t-il une capacité humaine que je possède déjà, ou prétend-il la remplacer ?

Ce que j’adopte

Les LLM locaux pour écrire des brouillons d’articles. J’écrivais déjà des articles avant. Le LLM accélère le brouillon initial, je garde la décision sur la forme finale.

Les scripts WP-CLI pour automatiser le déploiement multi-sites. Je savais déjà administrer un site WordPress. Le script m’évite de répéter quinze fois la même séquence de commandes.

Les newsletters mail. Je savais déjà écrire pour un lecteur. La newsletter prolonge cette compétence.

L’auto-hébergement. Je savais déjà ce qu’est un serveur. L’auto-hébergement me rend propriétaire de mes opérations.

Ce que je refuse

Les outils qui prétendent “penser à votre place” : assistants de productivité magiques, agents qui prennent vos décisions, plateformes qui résument vos réunions pour que vous puissiez en faire encore plus. Ces outils ne vous remplacent pas par de la machine — ils vous remplacent par une version dégradée de vous-mêmes qui ne sait plus ce qu’elle fait.

Les notifications push. Elles remplacent l’attention par la réaction. Je ne veux pas être un système réactif. Je veux être un système qui décide quand il regarde quoi.

Les réseaux sociaux pour le contenu pro. Ils prétendent remplacer le lien direct éditeur-lecteur par un algorithme. Ça marche pour 0,5% de créateurs et ruine 99,5% des autres en attention dépensée pour rien.

Les SaaS qui ne libèrent pas mes données dans un format ouvert. Si je ne peux pas exporter mes données et les rouvrir dans un autre outil, ce n’est pas mon outil, c’est ma prison.

La méthode pratique

Avant d’adopter un outil, je me pose les trois questions suivantes :

1. Quelle capacité humaine est concernée ? (Écrire ? Décider ? Mémoriser ? Communiquer ?)
2. L’outil l’amplifie ou la remplace ? Si je laissais l’outil pendant trois mois, est-ce que ma capacité se renforcerait ou s’atrophierait ?
3. Que se passe-t-il si l’outil disparaît demain ? Ai-je toujours une activité ou plus rien ?

Cette grille simple a éliminé 80% des outils dont je me croyais incapable de me passer. Et m’a fait économiser à peu près 250 € mensuels d’abonnements inutiles. Plus du temps. Beaucoup de temps.

Manifeste

Pourquoi je m’occupe encore de mes propres outils en 2026.

On me demande souvent pourquoi je n’utilise pas tel ou tel SaaS qui ferait “la même chose en mieux”. La réponse courte : parce que mes données ne sont pas chez eux. La réponse longue mérite un article.

Le diagnostic

En quinze ans, le numérique a opéré une bascule discrète. On est passés d’outils qu’on installe sur sa machine — propriété et maîtrise du logiciel — à des services qu’on loue mensuellement. Chaque outil pris isolément paraît raisonnable : 12 € pour la facturation, 8 € pour la newsletter, 25 € pour le projet, 15 € pour le mail pro, etc. Cumulés, on parle de 200 à 400 € mensuels rien que pour faire fonctionner une activité d’indépendant. Et le pire n’est pas le coût — c’est la dépendance.

Le jour où l’éditeur change ses conditions, ses tarifs, sa cible commerciale, ou disparaît tout simplement (cf. tous les SaaS rachetés et fermés ces dix dernières années), vous redémarrez à zéro. Vos données partent, votre workflow casse, vos clients voient passer un changement de communication. Tout ce travail invisible d’apprentissage de l’outil est perdu.

L’alternative

L’auto-hébergement n’est plus le terrain réservé aux geeks barbus de 2005. Avec WordPress + WooCommerce + un hébergement mutualisé à 15 € par mois, on couvre 80% des besoins d’un solo entrepreneur. Le 20% restant — ce qui demandait du code custom autrefois — est maintenant couvert par les LLM locaux, qui tournent sur un mini-PC à 600 € (achat unique, pas d’abonnement) et savent générer du code WordPress correct.

C’est cette équation qui m’a fait revenir au solo en 2023. Avant l’IA locale, gérer plusieurs sites en parallèle demandait soit un budget conséquent (équipe), soit une vie de moine technique (faire tout soi-même). Maintenant, l’IA prend en charge la part répétitive — surveillance, sauvegardes, rédaction de brouillons, analyses business — pendant que vous gardez la décision et l’expérience finale.

Ce que ça change concrètement

Je gère neuf sites WordPress en parallèle. Trois à cinq heures de travail concentré par jour, le matin. Le reste sert à penser et à marcher en forêt. Mon agent IA local me prévient si un site est en panne, fait les sauvegardes la nuit, m’envoie un brief des commandes le matin, et m’aide à rédiger les articles. Je relis, je corrige, je publie. La machine ne décide rien — elle exécute.

Le coût total mensuel de cette infrastructure ? 22 € chez IONOS (hébergement + DNS + mail). Plus l’électricité du mini-PC à la maison, soit ~ 5 € par mois. Pas d’abonnements à perte. Pas de “transformation digitale” à 30 000 €. Juste des outils choisis, alignés sur mes besoins.

Et pour vous ?

Si vous lisez cet article et que ça vous parle, posez-vous trois questions : (1) Quel pourcentage de votre activité dépend d’un SaaS unique aujourd’hui ? (2) Combien d’heures vous avez passées à apprendre cet outil, qui seraient perdues s’il disparaissait demain ? (3) Quelle est la valeur que vous tirez de ne PAS posséder vos outils ?

Si la réponse à la question 3 est “pas grand-chose à part la commodité initiale”, alors il est probablement temps de penser à reprendre la main. Pas demain matin tout d’un coup, mais étape par étape. Un outil après l’autre. C’est exactement ce que je fais depuis 2023, et c’est ce que j’aide d’autres à faire dans mes sessions de conseil.