FounderPulse testé pendant neuf jours : mémoire, exécution et limites d’un cofondateur IA

Le problème à comprendre

La question posée par FounderPulse dépasse son propre produit : où se situe désormais la valeur d’un assistant IA professionnel ? Dans la qualité de la réponse instantanée, ou dans la capacité à ne pas perdre le fil entre les réponses ?

Un LLM généraliste sait déjà suggérer une campagne de prospection, rédiger un message LinkedIn ou proposer un prix. Mais si l’utilisateur revient quinze jours plus tard, la qualité du système dépend de questions plus difficiles : quelle cible était réellement testée ? Pourquoi ce segment avait-il été choisi ? Combien de messages avaient été envoyés ? Quelle réponse avait été obtenue ? Une hypothèse avait-elle été invalidée ? Le prix actuel est-il celui décidé hier ou celui évoqué trois semaines plus tôt ?

FounderPulse transforme ce problème en boucle d’exécution. Le site public décrit quatre étapes : profilage, diagnostic du goulot, action unique et boucle de résultat. Le contexte devient une fiche business, une variable est identifiée comme blocage principal, une action est proposée avec une métrique, puis le résultat doit recalibrer le lendemain. La promesse est volontairement anti-to-do-list : une action, pas une liste ; un chiffre, pas un sentiment.

Cette contrainte est séduisante parce qu’elle déplace la fonction de l’IA. Au lieu de produire toujours plus de texte, le système essaie de conserver une décision et de forcer le retour du réel.

Ce que les faits montrent

FounderPulse est exploité par Bouquet Kevan, entrepreneur individuel en France. La page publique présente le produit comme un "AI business co-founder" et son fondateur explique l’avoir construit pour répondre chaque matin à une seule question : que faire aujourd’hui ? Le site insiste également sur quatre principes : une action plutôt qu’une liste, un chiffre plutôt qu’une impression, le contexte réel de l’utilisateur plutôt que des généralités, et la possibilité de retrouver FounderPulse dans les outils déjà utilisés, notamment Claude, ChatGPT et Cursor via MCP.

Au moment de notre vérification finale, la grille publique affichait Starter à 29 € par mois, Pro à 49 € et Scale à 119 €. Starter proposait sept jours d’essai avec carte, Pro quatorze jours, Scale aucun essai. Le diagnostic initial restait gratuit et sans compte. Pendant notre test, un e-mail spécifique a également proposé à notre compte historique un tarif de 19 € par mois conservé à vie en cas d’abonnement avant une date limite. Cette offre n’était pas la grille publique générale, mais un mécanisme de prix historique communiqué aux comptes existants.

La politique de confidentialité est assez précise sur la mémoire du Co-Fondateur. Elle mentionne les conversations, le contexte business, les faits, engagements et "patterns" conservés entre les sessions, ainsi qu’une possibilité de revue et d’effacement depuis les réglages. Elle indique également un hébergement principal via Lovable Cloud / Supabase en région européenne et l’utilisation de Google Gemini via Lovable AI Gateway pour le Co-Fondateur. FounderPulse affirme ne pas vendre les données et ne pas les utiliser pour entraîner le modèle, tout en précisant que certains sous-traitants, notamment Google et Stripe, peuvent opérer hors de l’Union européenne. Hébergement européen et chaîne de traitement exclusivement européenne ne sont donc pas synonymes, et la documentation du produit a le mérite de ne pas masquer cette nuance.

Le MCP constitue enfin une brique importante du positionnement. FounderPulse indique qu’un assistant externe peut lire la priorité du jour et le contexte business, puis réécrire les résultats obtenus. Si cette intégration devient fiable, le produit n’a plus besoin de battre ChatGPT ou Claude sur la génération de texte : il peut devenir la couche qui leur fournit l’état du business.

Notre protocole de test

Le compte FounderPulse comportait un contexte business suffisamment concret pour que le Co-Fondateur puisse générer des actions et des métriques : un outil d’audit web B2B autour du SEO, du GEO et de la visibilité IA, un MRR renseigné à 0 €, un objectif à 90 jours de 10 clients payants et un temps disponible de dix heures par semaine. Ces éléments servaient de contexte de test pour solliciter la mécanique du produit.

Ils ne doivent pas être confondus avec un test commercial de RoastMyURL. Nous n’avons pas demandé à FounderPulse d’entraîner, d’interroger, d’améliorer ou de piloter RoastMyURL, et nous n’avons pas utilisé les réponses du Co-Fondateur pour mesurer la capacité de RoastMyURL à trouver des clients. Les actions de prospection proposées dans FounderPulse ont surtout servi de support contrôlé pour observer ce que le système mémorisait, comment il réagissait à une non-exécution et si ses décisions restaient cohérentes d’une session à l’autre.

C’est une distinction méthodologique essentielle. Lorsque nous avons saisi 0 message envoyé sur 2, ce zéro décrivait l’état réel de l’action dans le compte FounderPulse : aucun message n’avait été envoyé. Il ne s’agissait ni d’un résultat de marché ni d’un test de conversion de RoastMyURL. De même, les cibles, messages et volumes proposés par le Co-Fondateur ont été analysés comme des sorties du système, pas comme les résultats d’une campagne commerciale réelle.

Le rôle réel de RoastMyURL dans l’analyse

RoastMyURL n’est intervenu qu’à côté du protocole FounderPulse. Nous avons utilisé notre outil pour réaliser un audit technique externe de founder-pulse.com, comme nous l’aurions fait pour n’importe quel site public. Le rapport a servi de photographie indépendante de certains signaux techniques du domaine et non de source de contexte injectée dans le Co-Fondateur.

Autrement dit, deux exercices distincts ont coexisté : d’un côté, un test longitudinal de la mémoire et de l’exécution de FounderPulse ; de l’autre, un scan technique du site founder-pulse.com avec RoastMyURL. Mélanger les deux donnerait artificiellement l’impression que FounderPulse a été évalué en pilotant RoastMyURL, ce qui n’a pas été le cas.

Ce que le terrain montre

Un zéro peut être une donnée utile

FounderPulse avait enregistré un engagement de test : envoyer deux messages de prise de contact. Nous n’en avions envoyé aucun, puisque l’objectif à ce stade était d’observer la mécanique de FounderPulse et non de mener une campagne commerciale. À la reconnexion, la plateforme a refusé de faire comme si rien ne s’était passé et nous a demandé le résultat de la veille. Nous avons donc saisi 0, ce qui était bien le résultat factuel de l’action enregistrée : zéro envoi.

Le produit a traité ce zéro comme une information, pas comme une case vide. Le Co-Fondateur a ensuite réduit l’action suivante à un seul message. La boucle annoncée publiquement devenait visible : engagement, résultat enregistré, adaptation. C’est probablement l’un des choix les plus solides du produit. Ici, le zéro ne disait rien du marché ; il permettait seulement de vérifier si FounderPulse savait utiliser correctement une action non exécutée au lieu de l’effacer de son histoire.

La difficulté est apparue dans l’explication donnée à ce zéro.

Quand une hypothèse prend l’apparence d’une statistique

À partir de la non-exécution, le Co-Fondateur a rapidement interprété le blocage comme psychologique. Il a évoqué la peur de déranger, le perfectionnisme puis le "refuge dans le faux travail". À un moment, il a attribué 80 % de confiance à cette hypothèse et formulé l’idée que, "dans 8 cas sur 10", le travail de préparation pouvait servir à éviter le verdict du marché.

Nous lui avons demandé la provenance de ce chiffre. La réponse a été explicite : il n’existait derrière ce "8 sur 10" aucune étude, aucune base statistique ni aucune mesure empirique. Le pourcentage était une formulation heuristique.

Le problème n’est pas qu’une IA formule une hypothèse. Un associé humain ferait exactement la même chose avec peu d’informations. Le problème apparaît lorsque l’intuition reçoit une précision numérique qui lui donne l’apparence d’une mesure. "Je soupçonne une friction à l’envoi" est une hypothèse. "Confiance 80 %" appelle une méthode de calibration.

FounderPulse a reconnu cette limite lorsque nous l’avons interrogé. C’est un point positif. Mais l’épisode a donné une règle de lecture pour tout le reste du test : plus le produit affiche un chiffre, plus la provenance de ce chiffre devient importante.

La mémoire persiste, mais sa provenance peut dériver

Le test le plus intéressant a concerné la cible commerciale. Nous avions déclaré une cible large. Au fil des échanges, FounderPulse a progressivement parlé comme si la cible principale était constituée d’agences web et de consultants SEO. Cette segmentation était défendable comme hypothèse commerciale. Elle ne l’était pas comme donnée utilisateur.

Lorsque nous avons demandé au Co-Fondateur d’indiquer la provenance de ses informations, il a d’abord présenté "agences web" comme une donnée de profil. Poussé à préciser, il a reconnu qu’il ne pouvait pas garantir une validation explicite de notre part : cette valeur venait d’une déduction consolidée à partir des échanges et des actions proposées.

Nous avons alors fourni une correction explicite, en demandant que la cible complète redevienne la source de vérité. Après fermeture puis reprise de session, FounderPulse a restitué correctement cette valeur et l’a attribuée à une déclaration utilisateur. La correction avait bien persisté.

Mais lorsqu’on lui a demandé ce qu’était devenue l’ancienne cible, le système a expliqué ne pas disposer d’un historique versionné avec anciennes valeurs, dates et raisons de changement. Quelques minutes plus tôt, il avait pourtant affirmé que les anciennes hypothèses étaient conservées, datées et reliées à la décision qui les invalidait. Confronté à la contradiction, il a corrigé son affirmation.

Cette séquence résume bien l’état de la mémoire observée : FounderPulse sait conserver un état courant, mais il ne sait pas encore raconter de manière fiable l’histoire de cet état.

L’"audit d’honnêteté" améliore la forme sans résoudre toute la traçabilité

Pendant notre test, Kevan a fait évoluer le Co-Fondateur avec une étape baptisée "audit d’honnêteté". Le principe est pertinent : séparer ce que le système sait, ce qu’il déduit et ce qui lui manque avant de proposer une action. Cette structure répond directement aux problèmes de confusion entre faits et hypothèses que nous avions observés.

Le résultat a été meilleur sur la forme. FounderPulse a effectivement commencé à étiqueter "fait enregistré", "déduction" ou "information inconnue". Il a également accepté, dans une séquence ultérieure, de répondre "inconnue" plutôt que d’inventer une date calendaire qu’il ne possédait pas.

Cette capacité à dire "je ne sais pas" plutôt qu’à compléter le vide par une réponse vraisemblable rejoint un autre fil éditorial de Kachouri : dans notre analyse de KENTA et de ses exigences de traçabilité et de preuve, nous avions déjà retrouvé la même question de fond : une IA crédible doit pouvoir distinguer ce qu’elle observe, ce qu’elle suppose et ce qu’elle est réellement capable de prouver.

Mais la traçabilité restait incomplète. Le Co-Fondateur a affirmé avoir identifié notre prétendue "procrastination productive" 14 fois, puis 15 fois. Interrogé sur ces quinze occurrences, il a d’abord présenté le nombre comme une vraie mesure. Lorsque nous lui avons demandé la liste chronologique des événements et la règle permettant de reproduire le compteur, il a finalement précisé qu’il ne conservait pas de log détaillé, seulement un agrégat dans ses notes de synthèse.

Ce cas est particulièrement instructif : mémoriser un nombre n’est pas conserver les preuves qui ont produit ce nombre. Même si l’agrégat est réellement persisté, il devient difficile de l’auditer si les événements sources ne sont plus disponibles. Et même si quinze échanges avaient effectivement porté sur l’audit du système, les qualifier ensuite de "procrastination" resterait une interprétation, pas une mesure.

Le plan lui-même pouvait changer sans nouvelle donnée

Après le résultat de 0 message sur 2, FounderPulse avait explicitement réduit le test suivant à un seul message. Pourtant, lors d’une reprise ultérieure, le système a demandé cinq messages sans qu’aucun nouveau résultat commercial n’ait été enregistré. Nous lui avons demandé quelle donnée justifiait le passage de 1 à 5. Il a reconnu qu’il s’agissait d’une erreur et est revenu à un seul message.

Quelques jours plus tard, la même dérive est réapparue : après avoir retrouvé correctement l’engagement à un message, FounderPulse est reparti vers cinq envois et un positionnement de vente directe aux agences SEO, sans nouveau résultat terrain permettant d’expliquer ce changement. Cette instabilité est importante, car la promesse du produit repose précisément sur l’idée que le résultat précédent recalibre l’action suivante. Si la taille ou la nature de l’action change entre deux sessions sans nouvel événement, il devient plus difficile de distinguer une véritable boucle d’apprentissage d’une nouvelle génération plausible du modèle.

Les e-mails prouvent la continuité hors session, mais aussi sa désynchronisation

Les relances e-mail ont constitué un autre terrain très utile. Elles utilisaient réellement des éléments du compte : taux d’exécution, objectif à 90 jours, contexte SEO et visibilité IA, engagement en cours ou période d’inactivité. FounderPulse ne se limite donc pas à une conversation ouverte ; une infrastructure de relance exploite bien une partie de l’état persistant.

Mais cette infrastructure ne racontait pas toujours la même histoire que le Co-Fondateur. Alors que le chat avait ramené l’action à un seul prospect, un e-mail demandait d’en contacter trois. Un autre template continuait à annoncer "3 actions à fort levier" tout en rappelant dynamiquement l’engagement à un message unique.

La divergence est devenue plus nette encore lorsqu’une relance nous a demandé d’"analyser la réponse unique" reçue et affirmait que nous avions "déjà une réponse en main avec 0 euros de revenu". Au même moment, le registre du Co-Fondateur conservait comme dernier résultat 0 message envoyé sur les 2 prévus. Dans notre protocole, aucun message commercial n’avait été envoyé et aucune réponse prospect réelle n’avait été enregistrée. L’e-mail faisait donc apparaître un événement commercial qui n’existait pas dans l’état que nous avions fourni au système.

Nous ne pouvons pas établir l’origine technique de cette divergence. Il peut s’agir d’un template, d’une donnée dérivée par erreur, d’un état intermédiaire ou d’une synchronisation incomplète entre composants. Mais l’enjeu est clair : une réponse prospect est un événement commercial simple ; elle devrait avoir le même état partout où FounderPulse l’utilise.

Le problème de mémoire devient alors un problème de source de vérité.

J8 : mieux vaut "inconnue" qu’une fausse précision

Au huitième jour, nous avons confronté FounderPulse à une contradiction temporelle : la veille, il indiquait que notre dernière activité remontait à six jours, tout en affirmant qu’un engagement avait été repoussé plusieurs fois depuis le 9 septembre. Cette fois, la réponse a été propre : "Inconnue, le système m’indique seulement “il y a 7 jours”, pas la date calendaire exacte."

Cette réponse paraît modeste, mais elle constitue une amélioration réelle. Une mémoire professionnelle ne doit pas toujours répondre ; elle doit aussi savoir refuser de transformer une information partielle en certitude. Le reste de la réponse a toutefois réintroduit les anciennes tensions : retour du diagnostic de "faux travail", changement de stratégie vers la vente directe et passage de nouveau à cinq messages.

La leçon est donc nuancée : FounderPulse a progressé dans la manière de qualifier certaines incertitudes, mais les règles de décision construites autour de ces données restaient encore instables.

Le produit a changé pendant que nous le testions

L’une des difficultés de cette analyse est aussi l’une des qualités de FounderPulse : le produit a évolué presque quotidiennement. Kevan nous a indiqué disposer d’une longue liste de prompts et de modifications à déployer progressivement. Pendant notre test, il a notamment retravaillé le raisonnement du Co-Fondateur, ajouté l’audit d’honnêteté, annoncé un bouton "L’IA se trompe ?", renforcé l’onboarding, regroupé des intégrations, travaillé sur des missions autonomes et ajusté le tunnel commercial.

Le fondateur nous a également annoncé une boucle où la prédiction du système serait comparée au résultat réel pour améliorer la calibration par segment et par type d’action. L’idée est prometteuse, mais notre test invite précisément à ne pas confondre le mot "calibration" avec une validation statistique. Lorsqu’il nous a donné une fourchette de 10 à 20 % de réponses pour du cold outreach B2B, nous lui avons demandé la source précise. FounderPulse a finalement reconnu ne pas disposer de l’étude brute dans sa base et a accepté de retirer le pourcentage de son raisonnement. C’est exactement le comportement attendu : une source absente doit conduire à déclasser le chiffre, pas à le défendre par habitude.

Le produit a aussi évolué côté abonnement. Le parcours visible en fin de test proposait Starter avec sept jours d’essai, Pro avec quatorze jours et Scale sans essai, carte requise pour les périodes d’essai et un seul essai par compte. Kevan nous avait auparavant signalé avoir corrigé le routage entre plans, la saisie des codes promotionnels et les comptes créés sans plan actif. Cette vitesse de modification rend indispensable de dater les observations : une critique exacte le lundi peut devenir obsolète le vendredi.

Un détour par robots.txt qui résume bien le problème du GEO

Kevan nous a également indiqué avoir "renforcé" le robots.txt pour mieux laisser le site être lu par les systèmes d’IA. Le fichier qu’il nous a transmis distinguait contenu public, espace authentifié et plusieurs user-agents comme GPTBot, ClaudeBot, Google-Extended ou Applebot-Extended. L’intention est saine : rendre explicite ce qui peut être exploré tout en gardant les zones privées hors crawl.

Mais ce petit fichier résume à lui seul la difficulté du discours "rendre un site lisible par les IA". Dans la version transmise, OAI-SearchBot n’apparaissait pas, alors qu’OpenAI recommande aujourd’hui de ne pas le bloquer pour faciliter la découverte et la citation dans ChatGPT Search. De même, Google précise que Google-Extended n’a pas d’incidence sur l’inclusion dans Google Search ; il sert notamment à contrôler certains usages liés à Gemini. Apple indique de son côté qu’Applebot-Extended n’explore pas les pages et sert à contrôler certains usages des données collectées par Applebot pour les modèles de fondation.

Autrement dit, "autoriser les IA" n’est pas un bouton unique. Recherche, crawl, citation, grounding et entraînement sont des usages différents. Ce constat vaut pour FounderPulse, mais aussi pour tous les outils GEO, y compris les nôtres : la readiness n’est pas la visibilité, et un fichier robots.txt n’est pas une preuve de citation.

Le test s’arrête sur l’écran de choix de plan

Le 12 septembre, alors que nous voulions effectuer une dernière passe, notre compte n’a plus ouvert l’espace FounderPulse habituel. L’interface affichait : "Ton espace s’ouvre dès qu’un plan est actif", puis proposait Starter, Pro ou Scale. Starter annonçait sept jours d’essai, Pro quatorze jours, Scale aucun essai. Nous pouvions donc poursuivre en activant un essai ou en payant immédiatement, mais nous avons décidé d’arrêter l’expérience à cet endroit.

Nous ne pouvons pas affirmer la cause de cette bascule. Le fondateur avait lui-même évoqué des bugs et plusieurs changements récents dans le parcours d’abonnement. Un précédent e-mail adressé à notre compte annonçait par ailleurs une période de transition pour l’accès sans abonnement. Il serait donc excessif de transformer cet écran en accusation sur le modèle commercial. Le fait établi est simplement que, le 12 septembre, notre compte de test ne permettait plus d’accéder à l’espace sans choisir un plan.

Cette interruption nous empêche de mener le test que nous voulions encore effectuer : envoyer un vrai message commercial, attendre un résultat réel, puis observer la comparaison entre prédiction et résultat dans la nouvelle boucle de calibration. Cette limite doit rester visible dans la conclusion.

Le mécanisme derrière le problème

Le mot "mémoire" recouvre plusieurs capacités qui ne doivent pas être confondues. Notre test en fait apparaître au moins quatre.

La première est la persistance d’état : conserver une cible, un objectif, un résultat ou un engagement entre deux sessions. FounderPulse sait le faire. Nous l’avons observé lorsqu’une cible corrigée a survécu à la reconnexion et lorsque le résultat 0/2 est revenu plusieurs jours plus tard.

La deuxième est la provenance : savoir si une donnée vient d’une déclaration utilisateur, d’un résultat enregistré, d’une déduction ou d’un résumé. C’est ici que des glissements sont apparus. Une cible déduite a pu être présentée comme donnée de profil ; un MRR explicitement saisi a ensuite été présenté comme déduit de l’absence de clients.

La troisième est la mémoire temporelle : conserver l’ancienne valeur, la nouvelle valeur, la date du changement et la raison de la correction. FounderPulse a explicitement reconnu ne pas pouvoir démontrer cet historique versionné dans notre test.

La quatrième est la synchronisation : garantir que le chat, le registre, les e-mails, les futures intégrations et les assistants MCP consomment le même état courant. Les relances contradictoires montrent que cette couche est au moins aussi importante que la mémoire elle-même.

C’est précisément la distinction que nous développons dans notre réflexion autour d’OAM, Organic Augmented Memory : une mémoire utile ne se contente pas de stocker une information ; elle relie information, contexte, version, décision et provenance. FounderPulse n’utilise pas OAM et il serait incorrect de lui prêter notre architecture. Mais il constitue un très bon cas pratique pour comprendre pourquoi une mémoire qui accompagne une décision dans le temps demande davantage qu’un simple résumé persistant.

Le diagnostic du goulot est surtout une méthode d’élimination

FounderPulse affirme publiquement identifier la variable qui bloque la croissance. Nous lui avons demandé comment il procédait. Le Co-Fondateur nous a décrit une logique d’élimination : si rien n’est exécuté, l’exécution devient le problème prioritaire ; si des messages sont envoyés sans exposition, le canal ou le volume sont interrogés ; s’il y a exposition sans réponse, la cible ou l’offre deviennent suspectes ; si les rendez-vous ne se transforment pas en ventes, le prix ou la confiance entrent dans l’analyse.

Cette mécanique est utile parce qu’elle transforme un problème vague en prochain test. Elle ne prouve pas pour autant qu’un goulot unique a été identifié au sens causal. Cent vues sans réponse peuvent venir de la cible, du message, de l’offre, du contexte ou de la crédibilité. Des rendez-vous sans vente peuvent refléter le prix, mais aussi le besoin, la maturité du prospect, son pouvoir de décision ou le produit lui-même.

La formulation la plus solide serait donc moins "FounderPulse trouve la seule variable qui bloque la croissance" que : FounderPulse formule une hypothèse de goulot et choisit une expérience destinée à produire la donnée manquante. C’est moins spectaculaire, mais plus défendable, et cela ne retire rien à la valeur opérationnelle de la méthode.

Le MCP pourrait devenir la vraie différenciation

FounderPulse devient particulièrement intéressant lorsqu’il cesse d’essayer d’être l’endroit où l’utilisateur doit tout faire. Le connecteur MCP présenté pour Claude, ChatGPT et Cursor permet théoriquement à un assistant externe de lire le contexte FounderPulse et la priorité du jour, puis d’écrire les résultats obtenus.

Si cette couche devient stable, FounderPulse peut éviter une bataille perdue d’avance contre les grands modèles généralistes. ChatGPT ou Claude savent déjà écrire un message commercial. Ce qui est beaucoup plus difficile à reproduire, c’est l’historique d’exécution qui explique pourquoi ce message existe, quelle hypothèse il teste, quel résultat il a produit et ce qui doit changer ensuite.

Dans cette lecture, FounderPulse n’est plus seulement un chatbot. Il devient potentiellement une infrastructure de continuité derrière plusieurs assistants. Mais cette ambition augmente d’autant l’exigence sur la provenance et la synchronisation : si plusieurs modèles lisent une même mémoire, cette mémoire doit devenir plus fiable que chacun d’eux pris séparément.

Cette architecture pose aussi une question de dépendance : plus la mémoire devient centrale, plus sa portabilité, son export, sa documentation et sa capacité de reprise comptent. C’est le même problème que celui abordé dans notre dossier sur les dépendances technologiques, leur cartographie et la capacité de sortie. Une mémoire utile ne doit pas seulement persister ; elle doit aussi rester récupérable et compréhensible si l’outil, le modèle ou le fournisseur change.

Ce que cela change

Le positionnement "AI business co-founder" est immédiatement compréhensible, mais il place la barre très haut. Un cofondateur ne donne pas seulement une tâche : il comprend l’histoire de l’entreprise, connaît les décisions remplacées, distingue un fait d’une intuition et sait pourquoi une stratégie a changé.

Notre test montre que FounderPulse est aujourd’hui plus mature sur la discipline d’exécution que sur cette mémoire stratégique complète. Le produit est très bon lorsqu’il rappelle un engagement, force la saisie d’un résultat, accepte un zéro et réduit une action. Il devient plus fragile lorsqu’il psychologise un comportement, transforme une heuristique en pourcentage, perd la provenance d’une donnée ou laisse plusieurs composants raconter des états différents.

C’est précisément pourquoi son meilleur positionnement futur pourrait être légèrement différent de celui d’un "cofondateur qui sait tout". FounderPulse pourrait devenir un système d’exécution et de mémoire décisionnelle pour fondateurs solos ou petites équipes, avec une promesse très défendable : ne pas perdre le fil entre ce que l’on voulait faire, ce que l’on a réellement fait et ce que le résultat autorise à conclure.

Pour un fondateur solo, un consultant, une petite agence ou un micro-SaaS dont les boucles commerciales sont courtes, cette discipline peut avoir une vraie valeur. L’adéquation est moins évidente lorsque les résultats apparaissent plusieurs mois plus tard, que de nombreux acteurs interviennent ou que la causalité entre une action et un résultat devient beaucoup plus difficile à établir.

À 29 ou 49 euros par mois, FounderPulse n’a pas besoin de remplacer un consultant ou un véritable associé pour être utile. Il doit surtout éviter assez de dispersion et conserver assez de continuité pour mériter une dépense récurrente. À 119 euros, avec plusieurs connecteurs, objectifs illimités et journal de décision, la qualité de la mémoire et de la traçabilité devient beaucoup plus directement une partie du produit vendu.

Ce que l’on ne peut pas conclure

Nous n’avons pas mené un test d’efficacité commerciale de FounderPulse. Le protocole ne cherchait pas à savoir si le produit augmente le chiffre d’affaires, améliore un taux de conversion ou permet réellement de trouver dix clients. Les actions commerciales générées dans le compte étaient des objets de test destinés à solliciter la mémoire, la provenance, les relances et la cohérence du système. Aucun résultat de marché ne doit donc être déduit de cet article.

Nous n’avons pas non plus testé FounderPulse comme outil de pilotage de RoastMyURL. RoastMyURL a uniquement servi, séparément, à auditer techniquement le site public founder-pulse.com. Il n’a pas été utilisé pour entraîner le Co-Fondateur, l’interroger, enrichir sa mémoire ou mesurer ses recommandations.

Enfin, nous n’avons pas pu tester complètement le MCP, la nouvelle mécanique de calibration, les missions autonomes, les benchmarks annoncés ou toutes les nouvelles intégrations. Plusieurs de ces éléments ont été communiqués par le fondateur pendant la période d’observation et doivent être considérés comme des évolutions annoncées ou partiellement observées, pas comme des capacités validées de bout en bout.

Cette séparation entre observation, interprétation et limite n’est pas seulement une précaution de cet article. Elle correspond au cadre que nous utilisons dans les repères vérifiables de Kachouri : dire ce qui est constaté, ce qui est inféré et ce qui resterait à démontrer avant de transformer une expérimentation en preuve.

Droit de réponse et évolution pendant le test

Kevan a été informé de notre démarche pendant la période d’observation. Nous lui avons transmis plusieurs remarques et il nous a signalé directement certaines corrections et évolutions. Plusieurs points soulevés au début du test ont ainsi été retravaillés pendant que nous poursuivions l’analyse : audit d’honnêteté, onboarding, intégrations, logique d’essai, interface et autres éléments du produit.

Cette réactivité doit être comptée dans l’évaluation. Il serait malhonnête de publier comme défaut actuel une erreur dont nous savons qu’elle a été corrigée. À l’inverse, une correction annoncée ne devient pas automatiquement une preuve tant que nous ne l’avons pas retestée. C’est pourquoi cet article décrit autant que possible la chronologie des observations plutôt qu’un verdict figé.

Ma lecture

FounderPulse est plus intéressant lorsqu’on cesse de lui demander s’il est "meilleur que ChatGPT". Ce n’est probablement pas la bonne compétition.

Sa vraie proposition de valeur tient dans une phrase beaucoup moins spectaculaire : "tu avais dit que tu ferais quelque chose ; quel chiffre as-tu réellement obtenu ?" Cette contrainte peut paraître triviale, mais elle déplace la valeur de l’IA depuis la production de texte vers la continuité de l’exécution.

C’est aussi à cet endroit que le test rejoint directement notre travail sur OAM, Organic Augmented Memory. OAM part précisément du problème que FounderPulse nous a permis d’observer en conditions réelles : une mémoire persistante n’est utile que si l’information conserve sa provenance, son statut, sa temporalité, ses relations et l’historique de ses révisions. Une cible déduite par l’IA ne devrait pas devenir silencieusement un fait utilisateur ; une ancienne valeur remplacée devrait rester retrouvable comme état historique ; une correction devrait pouvoir être reliée à la décision qui l’a provoquée.

Une architecture de ce type aurait donc adressé plusieurs faiblesses relevées pendant le test : dérive entre fait et hypothèse, disparition de l’ancienne valeur, difficulté à reconstruire la chronologie et dépendance excessive à la synthèse du modèle courant. Cela ne signifie pas qu’"ajouter OAM" aurait mécaniquement corrigé tous les problèmes de FounderPulse. La synchronisation entre le chat, le registre et les e-mails reste une question d’architecture applicative. Mais une couche de mémoire indépendante du modèle, qualifiée et révisable fournirait une base beaucoup plus robuste pour un produit dont la promesse repose justement sur la continuité.

Pendant neuf jours, le produit nous a montré qu’il savait déjà conserver certains états, rappeler des engagements, accepter une correction utilisateur, relancer hors session et exploiter un résultat enregistré. Il nous a aussi montré pourquoi cette ambition est difficile : une mémoire persistante n’est pas automatiquement une mémoire fiable ; un nombre stocké n’est pas nécessairement auditable ; une déduction n’est pas un fait ; et une plateforme ne possède pas réellement une source de vérité tant que ses différents composants peuvent raconter des versions différentes du même événement.

Le paradoxe est que ce sont précisément ces faiblesses qui rendent FounderPulse intéressant à suivre. Le produit essaie de résoudre un problème que tous les assistants professionnels vont rencontrer : comment maintenir une continuité utile lorsque les conversations, les modèles, les décisions et les résultats s’accumulent ?

Kevan a construit un système qui pousse parfois trop fort, interprète parfois trop vite et change encore très rapidement. Mais la direction mérite d’être prise au sérieux. Si FounderPulse parvient à relier proprement faits, hypothèses, décisions, actions et résultats, puis à partager cet état de manière cohérente entre chat, e-mail et assistants externes, il pourrait devenir quelque chose de plus défendable qu’un "cofondateur IA" de plus.

Il pourrait devenir la mémoire d’exécution qui empêche un business de recommencer chaque matin comme si la veille n’avait jamais existé.

C’est précisément la frontière que nous cherchons à documenter avec OAM : passer d’une mémoire qui se souvient "assez bien" à une mémoire capable d’expliquer ce qu’elle sait, d’où elle le sait, ce qui a changé et pourquoi.

Notre test s’arrête ici, non parce que toutes les réponses ont été obtenues, mais parce que l’accès au compte a cessé d’être disponible sans activation d’un plan. Cette interruption laisse plusieurs fonctions récentes non retestées, mais elle ne change pas le cœur du protocole : nous voulions tester les limites de la mémoire, de la provenance et de la continuité de FounderPulse, pas conduire une expérience commerciale avec RoastMyURL. Sur ce terrain précis, le produit nous a surtout appris que la continuité n’est jamais un simple bouton. Elle doit être construite, synchronisée, documentée et, surtout, vérifiable.