Je regarde six mois en arrière et j'ai déjà du mal à me rappeler comment nous travaillions il y a un an. Pas par nostalgie, par pure étrangeté. Comme quand on retourne dans une maison où l'on a vécu et qu'on ne reconnaît plus les pièces.
Cela a commencé comme une expérience sans nom. Aujourd'hui, elle n'en a toujours pas, mais elle a une forme reconnaissable. Chez Dcycle, toute l'entreprise contribue au code du produit. Pas seulement les ingénieurs. Le Customer Success déploie des automatisations. Le Marketing construit ses propres flux de données. Les Ops assemblent des dashboards qui nécessitaient auparavant trois réunions et un ticket. Personne n'a besoin de leur demander explicitement. Les outils le permettent, et la curiosité fait le reste.
Ce qui s'est passé, pendant cette expérience, c'est que la vitesse a changé la culture. Pas l'inverse. Ce n'est pas que nous avons d'abord conçu un manifeste d'autonomie, puis que les gens se sont mis à construire. C'est qu'une personne du CS en a eu assez d'attendre deux cycles pour résoudre un problème qu'elle connaissait bien, a ouvert Claude Code et l'a corrigé. Quand l'équipe a vu le résultat, personne n'a demandé si c'était "son rôle". Ils ont demandé comment faire.
Nous avions déjà le gène de l'autonomie en nous, mais les outils l'ont fait exploser.
Ce qui est une décision consciente, c'est de la maintenir. J'espère que chaque personne de cette équipe a le réflexe de résoudre avant celui de déléguer. Si vous voyez un problème et que vous pouvez le corriger, corrigez-le. Vous avez déjà la permission. Si vous ne pouvez pas, apprenez suffisamment pour pouvoir le faire la prochaine fois. Cherchez un moyen d'apprendre ; si vous n'en trouvez pas, demandez de l'aide. Vous trouverez toujours une main amicale à proximité.
Votre titre ne décrit plus ce que vous faites
Il y a quelque chose qu'on ne dit pas assez sur ce qui se passe quand tout le monde peut construire des solutions : votre titre cesse de décrire exclusivement ce que vous faites.
Marina est toujours au Customer Success. Mais la semaine dernière, elle a déployé un bot qui croise les données d'usage avec les signaux de churn et génère des alertes Slack suggérant des actions. Juan est toujours aux Finances, mais il a construit un système de réconciliation financière qui nous prenait deux jours et n'en prend plus que dix minutes. Ils n'ont pas cessé de faire leur travail. C'est que leur travail inclut désormais la conception des machines qui font une partie de leur travail.
Je sais que cela peut ressembler à un entrepreneur LinkedIn. Mais le vivre a un goût très différent de le lire. Le vivre ressemble davantage à une désorientation productive : le sentiment que ce que l'on savait faire ne suffit plus, mais que ce que l'on peut faire est plus que jamais. J'en sais quelque chose.
Managers de soi et de plusieurs
Nous appelons cela "managers de soi et de plusieurs" et je sais que cela semble étrange. Mais cela capture quelque chose de réel.
Chaque personne chez Dcycle gère son propre travail. C'est le "de soi". Elle a l'autonomie de décider quoi construire, comment résoudre un problème ou quand itérer. Elle n'attend pas d'approbation pour améliorer quelque chose. Le biais est à l'action.
Et chaque personne orchestre également des agents. C'est le "de plusieurs". Pas à la manière de la science-fiction. De manière pratique : elle conçoit des prompts, définit des flux, casse des choses et les répare, supervise les outputs, corrige les erreurs. Elle dispose d'une équipe d'agents qui amplifie sa capacité. Nous sommes passés de "faire" à "concevoir comment cela se fait", puis vérifier que c'est bien fait.
L'"Agent Manager" n'est pas un nouveau titre de poste (si vous le voyez quelque part, méfiez-vous, c'est le nouveau 'Directeur de l'Innovation'). C'est une nouvelle couche de compétence qui se situe sous tout le reste. Peu importe que vous soyez au CS, au produit ou aux ventes. Si vous ne savez pas orchestrer des agents, vous utilisez vingt pour cent de votre capacité et impactez dix pour cent de ce que vous pourriez.
Ce n'est pas optionnel. J'attends de chacun qu'il consacre du temps à apprendre à travailler avec des agents. C'est la différence entre quelqu'un qui exécute des tâches et quelqu'un qui conçoit des systèmes. Et ici, maintenant, nous cherchons les seconds.
Les silos, c'est terminé
Et voici la conséquence que j'ai le moins vue venir : les silos fonctionnels, c'est terminé. Pas parce que nous organisons un atelier de collaboration transversale. Pas parce que nous avons un OKR partagé. Ils se dissolvent parce que quand on peut faire plus de choses, on touche inévitablement plus de territoire.
La dépendance entre les équipes était le ciment qui maintenait les silos en place. En éliminant la dépendance, les silos perdent leur raison d'être. Ce qui reste, ce sont des personnes qui en savent de plus en plus sur tout et qui se déplacent entre les problèmes au lieu de se déplacer entre les départements.
Il n'y a pas de comité d'innovation. Il n'y a pas de laboratoire séparé du reste. Ce qu'il y a, c'est une boule de neige que chaque personne pousse dans une direction différente, et le résultat est quelque chose qu'aucun de nous n'aurait pu concevoir seul. La frontière n'est pas planifiée. Elle est découverte, chaque jour, quand quelqu'un franchit une limite que personne ne lui avait dit qu'il pouvait franchir.
Relisez cette phrase
La semaine dernière, notre Talent Manager a corrigé un bug en production. Il n'a pas choisi le mauvais métier. Il a vu quelque chose de cassé, a appris suffisamment pour le comprendre et l'a réparé. Bientôt, un développeur s'assiéra pour écouter des enregistrements d'appels de prospection, issus d'une cadence de prospection qu'un SDR aura conçue de bout en bout, mais qu'il n'exécute pas seul. Le SDR conçoit la stratégie, les agents l'exécutent, et le développeur veut toujours comprendre ce que disent les clients pour améliorer ce qu'il construit.
Un SDR qui conçoit mais n'exécute pas. Un développeur qui écoute des appels de vente. Un Talent Manager qui pousse du code. Si vous regardez cela avec la logique de l'organigramme, c'est un désastre. Si vous le regardez avec la logique des résultats, c'est le plus efficace que nous ayons jamais été.
Voilà ce qui se passe quand on arrête de protéger les frontières entre les rôles et qu'on commence à protéger la curiosité. La boule de neige grossit dans toutes les directions. Et la frontière n'est pas devant. Elle est partout.
Les tensions
Je ne veux pas dépeindre cela comme un Éden. Il y a des tensions.
La plus évidente : si tout le monde peut construire, qui décide ce qui est construit ? L'autonomie sans alignement, c'est le chaos. La réponse n'est pas moins d'autonomie, mais plus de visibilité. C'est pourquoi j'attends quelque chose de très précis : partagez ce que vous construisez, avant de le construire. Pensez à voix haute. Publiez avant de perfectionner. La transparence n'est pas un plus. C'est ce qui fait que l'autonomie fonctionne sans devenir de l'anarchie.
Il y a un piège silencieux dans la capacité à construire : il est très facile de confondre l'output avec l'outcome. Construire quelque chose qui fonctionne n'est pas la même chose que résoudre quelque chose qui compte.
Avant d'ouvrir Claude Code, avant de concevoir le flux, il y a une question que j'espère que chacun d'entre vous se pose : qu'est-ce qui doit être différent quand ce sera terminé ? Pas "que vais-je construire", mais "qu'est-ce qui doit avoir changé". L'output est le moyen ; l'outcome est le but.
Cela ne ralentit pas l'action : cela l'oriente. Un builder qui sait exactement ce qu'il essaie de changer construit plus vite, pas plus lentement, parce que chaque décision a un cap clair.
La deuxième tension : l'identité professionnelle. Si vous n'êtes plus "juste marketing" ou "juste ops", qu'êtes-vous ? Cela crée de l'inconfort. Il y a des personnes qui trouvaient de la sécurité dans la spécialisation et qui sentent maintenant le sol bouger. Je comprends. Mais j'espère que vous embrasserez cet inconfort plutôt que de le fuir. Parce que ce que vous êtes, c'est un builder qui connaît bien le marketing. Un learner qui maîtrise les ops. Votre expertise ne disparaît pas. Elle devient votre perspective, pas votre périmètre. Élargir le périmètre est signe d'une bonne direction.
60 personnes, 100x plus de capacité
Nous sommes les mêmes soixante personnes. Mais l'output de cette entreprise sera méconnaissable par rapport à il y a un an. Pas parce que nous travaillons plus d'heures. Nous travaillons, et travaillerons, le même nombre d'heures. C'est que chaque personne, avec une équipe d'agents derrière elle qui amplifie tout ce qu'elle fait, multiplie son rayon d'action par 100. Ce qui nécessitait deux personnes et une semaine, une seule personne peut maintenant le résoudre en un après-midi. Pas toujours. Mais de plus en plus.
Cela a d'énormes implications sur notre façon de penser la croissance. La question n'est plus "combien de personnes devons-nous recruter" mais "combien pouvons-nous amplifier la capacité de celles que nous avons déjà". Ce n'est pas un argument contre le recrutement. C'est un argument pour recruter différemment : des personnes qui savent orchestrer, qui apprennent vite, qui sont à l'aise dans l'ambiguïté d'un rôle qui change chaque trimestre. Et j'attends la même chose de ceux qui sont déjà là : que chaque mois, vous soyez capables de faire plus que le mois précédent. Pas plus d'heures. Plus de capacité.
Builders et learners
Voici comment nous décrivons ce que nous recherchons et comment nous abordons le travail.
Builder parce que vous construisez. Vous ne faites pas que penser, que planifier, que stratégiser (encore moins des PowerPoints). Vous mettez des choses au monde. Du code, des automatisations, des documents, des systèmes. Des choses qui fonctionnent, qui ont un output, que quelqu'un peut utiliser demain. J'attends que chaque semaine, chaque personne de cette équipe ait mis au monde quelque chose qui n'existait pas lundi.
Learner parce que ce que vous savez aujourd'hui ne suffit pas pour demain. Il y a six mois, personne dans cette équipe ne savait orchestrer des agents. Il y a trois mois, certains le faisaient avec difficulté. Aujourd'hui, cela devient la norme. La vitesse à laquelle les outils évoluent, le seuil du possible, exige une vitesse d'apprentissage équivalente. N'attendez pas que quelqu'un vienne vous former. Allez apprendre. C'est plus facile que jamais. Celui qui arrête d'apprendre s'arrête. J'attends une curiosité inlassable. J'attends que vous cassiez des choses en essayant. J'attends des questions avant des certitudes. Si vous avez appris quelque chose de nouveau, partagez-le, à l'intérieur et à l'extérieur de Dcycle.
Ce ne sont pas deux choses différentes. C'est la même : vous construisez pour apprendre et vous apprenez pour construire.
Ma part
Tout ce qui précède est ce que j'attends de vous. Maintenant, ma part.
Si je vous demande de construire, je m'engage à dégager le chemin. Chaque processus qui n'apporte rien, chaque approbation qui n'existe que par inertie, chaque réunion qui pourrait être un message : c'est ma responsabilité de l'éliminer. Signalez-le quand vous le voyez. Votre énergie doit aller à la construction, pas à la navigation bureaucratique.
Si je vous demande de casser des choses en essayant, je m'engage à ce que casser des choses n'ait aucune conséquence. L'erreur de bonne foi n'est pas pénalisée ici. Elle est analysée, on en tire les leçons, et on avance. La seule erreur impardonnable est de ne pas essayer. Si vous sentez un jour que se tromper a un coût politique, dites-le-moi. Parce que cela signifiera que quelque chose dans la culture s'est cassé, et le réparer sera ma priorité numéro un.
Et si je vous demande d'apprendre constamment, je m'engage à apprendre avec vous. Pas depuis un bureau. Depuis les mêmes tranchées. Si j'arrête de construire, de casser des choses, de poser des questions inconfortables, vous avez le droit de me le signaler. Ce pacte fonctionne dans les deux sens ou il ne fonctionne pas.
Le plus transformateur de tout
Je ne sais pas si dans un an nous travaillerons encore exactement comme cela. Probablement pas. Nous aurons probablement découvert des problèmes que nous ne voyons pas aujourd'hui, et inventé des solutions que nous ne pouvons pas imaginer maintenant.
Et cela, je crois, est le plus transformateur de tout. Pas la technologie. Pas les agents. Pas le code. C'est l'état d'esprit de quelqu'un qui arrête d'attendre et commence à résoudre. De quelqu'un qui voit un problème et, au lieu d'escalader, construit. C'est ce que j'attends de chaque personne dans cette entreprise. Ni plus, ni moins.
Voici comment nous travaillons chez Dcycle. Builders. Learners. Managers de soi et de plusieurs. Et le chemin continue de se faire en marchant.
J.