Des mises à jour produit agentiques à un GTM construit avec l’IA

Cette semaine a été une de ces rares semaines de fondateur où une douzaine de chantiers qui semblaient séparés se sont soudain mis à se renforcer les uns les autres.

Côté produit, on stabilise pour la bêta une timeline cinématique avec un harness de debug, un gestionnaire de tâches, un éditeur de notes en direct et un mode vocal persistant sur l’app Desktop. Côté ingénierie, on resserre la façon dont travaillent les agents de code, pour qu’ils ne se contentent pas d’écrire du code mais prouvent aussi que ce code survit à la réalité. Et côté GTM, on construit le même genre de système pour la croissance : un système où le contexte s’accumule, où le contenu est réutilisé, et où la machine s’améliore chaque semaine au lieu de repartir de zéro à chaque fois.

Si je devais résumer ce qui change chez Notis en ce moment, ce serait ça : on passe de tours de magie IA isolés à une forme d’intelligence plus opérationnelle.

Timeline cinématique et harness de debug : comment les mises à jour produit agentiques passent de la stabilisation en bêta à la mise en production.

Le produit commence à devenir cohérent

Beaucoup de développement produit paraît chaotique vu de l’extérieur, parce que les utilisateurs ne voient que la version finale soignée, pas la période où plusieurs briques sont fiabilisées en même temps.

C’est exactement la phase dans laquelle on est.

Cette semaine, on stabilise quatre surfaces importantes pour la bêta :

• Une timeline plus cinématique et un harness de debug

• Un gestionnaire de tâches qui rend le suivi plus visible

• Un éditeur de notes en direct qui rend la rédaction assistée par IA moins fragile

• Un mode vocal persistant sur l’app Desktop qui garde Notis disponible comme un vrai compagnon de travail, pas comme une boîte à prompt ponctuelle

L’objectif est de pousser ces changements en production vers le 20 avril si la stabilité tient.

Cette date compte moins que ce qu’elle représente. Le vrai jalon, ce n’est pas de livrer des fonctionnalités une par une. C’est de faire en sorte que le produit ressemble à un seul environnement plutôt qu’à un assemblage de capacités déconnectées.

C’est là que beaucoup de produits IA s’effondrent encore. Ils font de superbes démos, mais ils ne tiennent pas encore debout comme un système qui fonctionne. Je me soucie moins de savoir si quelque chose a l’air magique dans une vidéo que de savoir si ça continue de livrer à la dixième, à la cinquantième et à la centième utilisation.

On a changé les règles pour nos agents de code

L’un des plus gros goulets d’étranglement du développement produit pensé pour l’IA, ce n’est pas la génération de code. C’est la validation.

Il est étonnamment facile pour un agent d’écrire quelque chose qui a l’air correct. Il est beaucoup plus difficile pour ce même agent de prouver que le changement fonctionne dans le système réel.

Alors on a resserré la boucle.

On attend de plus en plus de nos agents de code qu’ils fassent quatre choses avant que je fasse confiance au résultat :

1. Écrire des tests de non-régression

2. Lancer des tests de bout en bout sur de vrais canaux

3. Inspecter les traces Langfuse

4. Valider les changements d’interface directement dans le navigateur

Développement produit piloté par des agents : les agents de code valident chaque changement par des tests, des exécutions réelles, la revue des traces et des vérifications dans le navigateur avant de livrer.

Ça paraît évident. En pratique, ça change tout.

Dès que tu obliges un agent à vérifier son propre travail sur de vrais parcours utilisateurs, tu arrêtes de le traiter comme un moteur d’autocomplétion et tu commences à le traiter davantage comme un opérateur junior. Il a toujours besoin de supervision. Il échoue toujours de manière étrange. Mais il peut maintenant gérer des cycles de travail autonome bien plus longs sans semer le chaos.

On commence à débloquer des plages de plus de 30 minutes où les agents peuvent travailler avec beaucoup moins d’interruptions manuelles, parce que la charge des tests n’est plus entièrement renvoyée aux humains.

Ça compte plus qu’on ne le pense.

Le vrai frein du développement agentique, ce n’est souvent pas la qualité de génération. C’est le fondateur ou l’ingénieur qui devient la couche de QA universelle pour chaque petit changement. Une fois que ça arrive, le système arrête de suivre ton ambition.

La couche de debug devient un avantage produit

Je suis de plus en plus convaincu que l’observabilité n’est pas un bonus pour les produits IA. Elle fait partie du produit.

Si des agents doivent faire un travail qui compte, tu dois comprendre non seulement ce qu’ils ont produit, mais comment ils y sont arrivés, où ils ont échoué et quelles hypothèses ont cassé en chemin.

C’est pour ça que l’inspection des traces devient une partie du workflow de développement plutôt qu’une réflexion après coup. Langfuse est particulièrement utile ici, parce qu’il nous permet d’inspecter ce qui s’est passé à l’intérieur d’une exécution au lieu de deviner à partir du seul résultat.

C’est une de ces fondations qui ont l’air ennuyeuses et qui deviennent un avantage stratégique avec le temps.

Les entreprises qui gagneront dans le logiciel agentique n’auront pas seulement les démos les plus spectaculaires. Elles auront la meilleure discipline de debug.

La fiabilité bat le battage autour des modèles

Une grande partie de la conversation sur l’IA reste trop centrée sur l’identité des modèles, comme si choisir le bon modèle était toute la stratégie.

Le choix du modèle compte, bien sûr. En ce moment, j’ai encore des préférences selon le type de travail :

• Opus a tendance à être plus fort pour la planification et le raisonnement sur l’interface

• ChatGPT a tendance à être plus fort pour faire aboutir les builds

Mais ces préférences ne comptent qu’à l’intérieur d’un système plus large.

Par exemple, on a récemment réglé un problème de limite de débit chez OpenAI en implémentant plus soigneusement un backoff progressif. Ce genre de travail n’a rien de glamour. Personne n’en partage une capture sur X avec une musique dramatique en fond. Mais c’est souvent ce qui fait la différence entre un produit qui paraît fiable et un produit qui paraît capricieux au hasard.

Plus je construis dans ce domaine, moins je crois que l’avantage défensif tient à un modèle en particulier. L’avantage, c’est le système autour : routage, observabilité, tests, logique de reprise, mémoire et design d’interface.

On construit le GTM avec la même logique agentique

Le plus intéressant cette semaine, c’est que le côté GTM commence à refléter le côté produit.

On synchronise des sources comme Notion, Gmail, Drive et des sites web pour qu’elles servent de couches de mémoire à l’exécution en aval. Ça crée un système de contexte bien plus durable que de tout re-briefer de zéro en permanence.

Une fois ces sources connectées, un agent externe peut transformer ce contexte en :

• Articles de blog

• Publicités

• Contenus pour les réseaux sociaux

• Matière pour des landing pages

L’orchestration GTM par l’IA transforme des connaissances éparpillées dans plusieurs outils en un moteur continu de contenu, de campagnes et de croissance.

Ce n’est pas qu’une question d’efficacité sur le contenu. C’est une stratégie pour faire fructifier le contexte.

La plupart des petites équipes ne manquent pas vraiment d’idées. Elles manquent d’un moyen fiable de transformer ce qu’elles savent déjà en distribution régulière.

C’est aussi pour ça que je teste un développeur web avec une rémunération forfaitaire d’environ 2 000 $ par mois pour produire des landing pages SEO programmatiques. Je ne vois pas ça comme « faire du marketing à la main avec un peu d’IA par-dessus ». Je le vois comme la construction d’un moteur GTM pensé pour l’IA, où mémoire structurée, contexte réutilisable et workflows d’exécution se renforcent mutuellement.

Et surtout, ça valide quelque chose de plus grand : il existe une vraie demande pour des capacités GTM natives dans Notis lui-même.

Les utilisateurs ne veulent pas seulement un assistant qui capture leurs idées. Ils en veulent un qui les aide à transformer ces idées en distribution.

Le GTM par l’IA, ce n’est pas spammer plus vite

Il existe une version paresseuse de la croissance par l’IA qui dit en gros : produire plus de contenu, plus de pubs, plus de pages, plus de bruit.

Je ne pense pas que ça marche longtemps.

La meilleure version, c’est d’utiliser l’IA pour augmenter la pertinence et la continuité.

Si ta couche de mémoire contient la réflexion du fondateur, le langage des clients, les mises à jour produit, le positionnement passé, les documents internes et des transcriptions réelles, alors l’IA peut t’aider à produire une distribution qui sonne vraiment ancrée. Pas générique. Pas déconnectée. Pas du « content marketing » au sens mort et corporate du terme.

C’est cette différence qui m’importe.

Le but n’est pas d’industrialiser la bouillie. Le but est de faire paraître une petite équipe plus cohérente, plus constante et plus prolifique que sa taille ne le permettrait normalement.

Pourquoi tout ça semble connecté maintenant

Quand je prends du recul, trois choses qui semblaient séparées commencent à fusionner :

• Le développement produit

• La fiabilité des agents

• L’exécution go-to-market

Elles reposent toutes sur les mêmes principes de base :

• Une bonne mémoire

• Des boucles de vérification claires

• Des interfaces avec moins de friction

• Des systèmes qui s’améliorent à l’usage

C’est pour ça que je suis de plus en plus sceptique face aux produits IA qui se concentrent uniquement sur une fine couche de chat. La vraie valeur apparaît quand l’assistant est branché sur tes workflows, tes traces, tes canaux, tes documents et ton contexte opérationnel.

C’est aussi pour ça que je pense que la frontière entre « produit » et « opérations » va s’estomper. Les entreprises qui gagneront ne se contenteront pas de livrer du logiciel. Elles construiront des systèmes qui les aident à livrer, apprendre, distribuer et s’améliorer plus vite que des équipes de taille comparable.

Un dernier mot de fondateur

Il y avait aussi une possible mise en relation avec un investisseur via Adrian cette semaine, ce que j’apprécie.

Mais pour être honnête, ce genre de moment renforce surtout une conviction que j’avais déjà : la levée de fonds compte bien moins que le fait que la machine sous l’entreprise devienne plus solide.

Quand je regarde Notis aujourd’hui, ce qui me rend optimiste, ce n’est pas un lancement de fonctionnalité ou une conversation en particulier. C’est que les boucles s’améliorent.

Le produit devient plus cohérent.

Les agents deviennent plus responsables.

Le système GTM devient plus riche en contexte.

C’est ça, le vrai progrès.

Et si on réussit, la valeur à long terme de Notis ne sera pas de t’aider à poser de meilleures questions. Ce sera d’aider les petites équipes à construire des systèmes d’exécution qui continuent de livrer pendant qu’elles dorment.

Actions à mener et questions ouvertes

Voici ce sur quoi je me concentre ensuite :

• Stabiliser suffisamment les surfaces de la bêta pour permettre un passage en production vers le 20 avril

• Continuer à relever les exigences de vérification des agents de code

• Transformer les workflows GTM connectés à la mémoire en playbooks internes reproductibles

• Comprendre si l’attraction la plus forte reste la productivité, ou si le GTM pensé pour l’IA devient un point d’entrée tout aussi important

La question intéressante n’est plus de savoir si l’IA peut générer un résultat utile.

Elle le peut clairement.

La question, c’est de savoir si on peut construire des systèmes où ce résultat se transforme en élan produit, en levier opérationnel et en vraie distribution.

C’est le jeu qui, à mon avis, vaut la peine d’être joué.