Une bonne stack ne doit pas impressionner.
Elle doit tenir.
Quand tu gères un business sans équipe technique, le piège est de vouloir empiler des outils pour donner l'impression d'avoir un système avancé. Un outil pour le CRM. Un autre pour les formulaires. Un autre pour les tâches. Un autre pour la newsletter. Un autre pour les automatisations. Un autre pour la base de connaissance. Puis un outil pour synchroniser les outils.
Au bout d'un moment, tu ne gères plus ton business.
Tu gères ta stack.
Ma logique est différente : je préfère une stack courte, compréhensible et connectée autour de rôles très clairs.
Le but n'est pas d'avoir l'outil parfait dans chaque catégorie. Le but est d'avoir un système qui permet de publier, vendre, suivre, automatiser et apprendre sans passer toute la semaine à maintenir l'infrastructure.
Le principe : chaque outil doit avoir un rôle
Avant de parler d'outils, il faut parler de rôles.
Dans une stack simple, chaque outil doit répondre à une question :
- où est-ce que je publie ?
- où est-ce que je collecte l'audience ?
- où est-ce que je stocke les données ?
- où est-ce que j'automatise ?
- où est-ce que je communique ?
- où est-ce que je mesure ?
- où est-ce que je documente ?
Si deux outils font exactement la même chose, il faut choisir.
Le doublon est l'ennemi d'une stack légère.
Ce n'est pas grave d'avoir plusieurs outils. Ce qui est dangereux, c'est d'avoir plusieurs sources de vérité.
Contenu : markdown versionné dans Git pour publier les articles
Pour le blog, les articles sont des fichiers markdown stockés directement dans le code source du site.
L'objectif est simple : garder le contrôle total sur le contenu, sans dépendre d'un SaaS externe qui peut changer ses règles du jour au lendemain.
Les articles vivent dans le repo Git. Le site les compile et les affiche au build. Ça permet de garder un workflow de publication propre : créer une branche, rédiger, relire, merger sur main — et la publication est déclenchée par Vercel.
Ce choix est cohérent avec ma priorité actuelle : publier régulièrement sans me battre avec l'infrastructure éditoriale, et sans dépendance externe sur le contenu lui-même.
Ce que j'attends d'un système de publication :
- écrire vite, dans n'importe quel éditeur ;
- gérer les titres, descriptions et images ;
- garder les articles structurés ;
- permettre une publication propre ;
- rester entièrement sous mon contrôle.
Je ne cherche pas l'outil le plus complexe.
Je cherche celui qui me permet de maintenir le rythme.
Site : Next.js pour contrôler l'expérience
Le site est construit avec Next.js.
Pourquoi ne pas tout laisser dans une plateforme de blog classique ?
Parce que je veux contrôler plus que les articles.
Le site doit aussi porter :
- la page d'accueil ;
- les deals ;
- la newsletter ;
- la page projets ;
- les pages de confiance ;
- le SEO technique ;
- la structure long terme.
Le blog n'est pas seulement un flux d'articles. C'est un actif.
Next.js permet de garder cette flexibilité sans perdre la performance.
Je peux stocker les articles en markdown, garder les deals en local, ajouter des pages spécifiques et structurer le site comme un vrai système d'acquisition.
Automatisation : Make pour orchestrer
Make reste un outil central dans ma stack.
Pas parce que tout doit passer par Make.
Mais parce qu'il est très utile pour connecter rapidement des outils sans écrire un backend complet à chaque fois.
Je l'utilise surtout pour des workflows comme :
- synchroniser des données ;
- envoyer des notifications ;
- transformer des informations ;
- déclencher des actions après un formulaire ;
- préparer des brouillons ;
- mettre à jour des bases ;
- relier des outils qui ne se parlent pas naturellement.
Ce que j'aime avec Make, c'est la visibilité.
Tu peux voir le scénario. Tu peux comprendre le chemin. Tu peux tester module par module. Pour un fondateur ou un opérationnel non développeur, c'est important.
Mais je garde une règle :
Make ne doit pas devenir une boîte noire.
Chaque scénario important doit être nommé, documenté et construit autour d'un process clair.
Données : Notion ou Airtable selon le besoin
Notion et Airtable peuvent se ressembler de loin.
Mais je ne les utilise pas exactement pour la même chose.
Notion pour la documentation et les espaces de travail
Notion est très bon pour :
- documenter ;
- écrire des process ;
- suivre des idées ;
- structurer une base de connaissance ;
- gérer des pages internes ;
- créer des espaces projet légers.
Je le vois comme un outil de clarté.
Quand une information doit être lue, expliquée ou partagée avec du contexte, Notion est pratique.
Airtable pour les données plus structurées
Airtable est plus adapté quand la donnée devient vraiment centrale.
Exemples :
- deals ;
- CRM simple ;
- base d'outils ;
- pipeline éditorial ;
- catalogue ;
- inventaire de ressources.
Quand j'ai besoin de vues, filtres, champs structurés et potentiel d'import/export propre, Airtable devient plus intéressant.
La règle simple :
- si c'est surtout du contenu et du contexte, Notion ;
- si c'est surtout de la donnée structurée, Airtable.
Newsletter : Beehiiv pour construire l'audience
La newsletter est une pièce importante.
Un visiteur qui lit un article peut partir et ne jamais revenir. Un abonné newsletter devient une relation directe.
Beehiiv sert à gérer cette relation.
Je veux que la newsletter reste simple :
- un système utile par semaine ;
- quelques liens ou outils intéressants ;
- des coulisses ;
- pas de remplissage.
La newsletter n'est pas juste un formulaire en bas de page.
C'est le pont entre le contenu public et l'audience récurrente.
Le site pousse vers la newsletter. Les articles nourrissent la newsletter. La newsletter redistribue les articles. À terme, les deals et les projets peuvent aussi y trouver leur place.
Email transactionnel : Resend pour les envois propres
Pour les emails transactionnels, je préfère utiliser un outil dédié.
La newsletter et les emails transactionnels n'ont pas le même rôle.
La newsletter sert à envoyer du contenu à une audience.
Les emails transactionnels servent à envoyer des messages liés à une action précise :
- confirmation ;
- contact ;
- notification ;
- message système ;
- suivi spécifique.
Resend est pensé pour ce type d'usage.
Le point important : ne pas mélanger tous les emails dans le même sac.
Un email marketing et un email transactionnel n'ont pas la même logique, ni les mêmes attentes.
Communication : Gmail et Google Workspace
Il ne faut pas sous-estimer les outils simples.
Gmail, Google Drive, Google Docs et Google Sheets restent très utiles dans une stack légère.
Beaucoup de workflows business passent encore par :
- un email ;
- un document ;
- un dossier ;
- une feuille de suivi ;
- un lien partagé.
Ce n'est pas toujours glamour, mais c'est réel.
L'automatisation ne consiste pas à remplacer tous ces outils. Elle consiste souvent à mieux les relier.
Créer automatiquement un dossier Drive, préremplir un document, envoyer une notification Gmail ou archiver une réponse peut déjà faire gagner du temps.
IA : utile, mais pas au centre de tout
J'utilise l'IA comme une couche d'assistance.
Pas comme un remplacement complet du système.
L'IA est utile pour :
- résumer ;
- reformuler ;
- structurer des idées ;
- analyser un texte ;
- préparer un brouillon ;
- classer une demande ;
- accélérer une recherche.
Mais je ne veux pas que chaque workflow dépende d'une décision IA.
Quand une règle simple suffit, je préfère une règle simple.
L'IA doit intervenir là où il y a vraiment besoin d'interprétation.
Ce que je n'ajoute pas encore
Une stack saine, ce n'est pas seulement ce qu'on ajoute.
C'est aussi ce qu'on refuse.
En V1, je n'ai pas besoin de :
- un CRM trop lourd ;
- une plateforme marketing complexe ;
- un data warehouse ;
- dix dashboards ;
- un outil de gestion projet enterprise ;
- une stack analytics surdimensionnée ;
- un agent IA partout.
Je préfère d'abord publier, apprendre, suivre les signaux importants et améliorer progressivement.
La complexité doit se mériter.
Comment choisir ta propre stack
Tu n'as pas besoin de copier ma stack.
Tu dois comprendre ta logique.
Commence par ces questions :
- où sont mes clients ou prospects ?
- où sont mes contenus ?
- où sont mes données importantes ?
- quelles tâches se répètent ?
- quels outils sont déjà utilisés ?
- où est-ce que je perds du temps ?
- quelles erreurs reviennent souvent ?
- quel outil est la source de vérité pour chaque donnée ?
Ensuite, construis autour de rôles.
Pas autour de tendances.
Une bonne stack pour un fondateur solo doit être :
- simple à comprendre ;
- facile à maintenir ;
- assez flexible ;
- connectable ;
- documentée ;
- adaptée au volume réel.
Conclusion
Ma stack automation 2026 n'est pas une collection d'outils à la mode.
C'est un système léger pour écrire, publier, automatiser, suivre et construire sans équipe technique.
Le point important n'est pas d'avoir Make, Notion, Beehiiv ou Airtable.
Le point important est de savoir quel rôle chaque outil joue.
Quand les rôles sont clairs, la stack devient un levier.
Quand les rôles sont flous, elle devient une charge.
Si tu construis ton business sans équipe technique, ne cherche pas d'abord la stack parfaite.
Cherche une stack que tu peux comprendre, maintenir et améliorer chaque semaine.
