Comment une tâche devient de la production
Ma façon de travailler en 2026 : chaque tâche passe d'abord deux filtres — peut-elle éviter le travail manuel et l'écriture peut-elle être accélérée — et n'atteint le code qu'ensuite. Ci-dessous, toute la chaîne, étape par étape.
Prérequis — propriétaire ou exécutantLe filtre ne fonctionne que lorsque je suis propriétaire de mon domaine
Promova a recâblé ma façon de penser : pas juste être développeur, mais valider chaque tâche qui m'arrive. Pas « comment je construis ça » mais « qu'est-ce que ça apporte au business ». Ce filtre, cependant, ne fonctionne que sous une condition.
La tâche passe aussitôt par le filtre. Je réponds du résultat, donc j'ai la légitimité de dire « ça ne devrait pas être construit du tout » ou « ça ne devrait pas être construit par moi ».
Pas de filtre. Il y a une tâche, une échéance et une livraison. Rien de mal à ça — c'est simplement un autre contrat.
La différence n'est pas la compétence, c'est le mandat. Une unité indépendante, pleinement propriétaire de son domaine, coûte moins à l'entreprise qu'un exécutant — parce qu'elle ne construit pas l'inutile.
Avant le code
Une tâche arrive
Je ne commence pas par « comment je construis ça ». La première question, c'est ce que ça apporte au business ; la seconde, si ça doit vraiment être fait à la main, et par moi.
Filtre un — peut-on éviter tout travail manuel ?
Trois sorties, et toutes les trois répondent à une question : qui s'en charge désormais. Si la tâche en prend une, elle cesse d'être la mienne, et ma capacité reste libre pour ce qui a vraiment besoin d'un développeur.
sorties du pipeline- Géré par un agent
Configuré une fois, et ça ne revient plus à personne. À partir de là, un agent tourne et l'accomplit entièrement seul, sans la moindre intervention.
Revue de code automatique · l'analytics tombe directement dans un canal Slack dédié, au lieu d'extraire les logs à la main
- Géré par le demandeur
La tâche ne m'atteint même pas. Celui qui en a besoin la fait lui-même avec l'IA — mon rôle, c'est de bâtir le chemin une seule fois.
Mailing d'outreach · plateforme d'influenceurs
- Géré par l'équipe
Une fonctionnalité ou un plugin cousu dans le système, par lequel l'équipe fait ses changements elle-même — sans ticket, sans développeur.
Plugin de redirections dans le CMS, aux mains de l'équipe SEO
Filtre deux — accélérer l'écriture elle-même
La tâche a passé le filtre un, donc elle est à moi. Question suivante : est-ce de la routine côté code ? Si le motif se répète — styles de bouton, une structure récurrente — j'écris d'abord un skill pour ça, et le code seulement ensuite. Plus long une fois, plus rapide chaque fois d'après.
Décision
Plan mode — l'analyse avant la moindre ligne
Je dois vivre ce code, pas le recevoir. Le plan décide qui l'écrit.
- Je ne connais pas ce code
- Je l'écris moi-même.
- Je connais ce code
- C'est l'agent qui l'écrit.
- Je ne le connaissais pas, mais le plan l'a éclairci
- C'est l'agent qui l'écrit.
Livraison
Implémentation
Celui que le plan a désigné se met à écrire — moi ou l'agent.
Vérifications en dev — l'agent
C'est l'agent qui vérifie, pas moi : il parcourt le flow via Playwright ou lit les erreurs directement depuis le dev server Next.js via MCP. Aucune de ma capacité n'y passe.
Vérifications en mode build — l'agent
Le dev ment. Chunks différents, optimisations différentes, comportement différent. Un truc qui marche en dev et meurt au build, c'est un classique, donc le build a sa propre passe — pilotée là encore par l'agent.
Tests unitaires + Playwright
Seulement une fois que ça marche vraiment. Tests unitaires pour la logique, Playwright pour le flow — écrits par l'agent, eux aussi.
Staging — là, j'interviens
Le premier point que je vérifie moi-même, à la main. En local seulement si la tâche est sensible. Ensuite ça part en QA — dans cet ordre, pas l'inverse.
Pull request
Relu par des agents portant les skills qui gouvernent cette zone du projet : un changement de performance est confronté aux règles de performance, un changement de paiement aux règles de paiement.
Production
Mise en production.
Vérification finale
QA en production. Si ça tient — terminé.
- OOP
- SOLID
- DRY
- KISS
- YAGNI
- CI/CD
En connaissant les pratiques d'architecture et en tenant l'ordre des étapes, on peut écrire du code vite et bien à la fois. La vitesse vient de la séquence, pas d'une frappe plus rapide.
L'expertise dans une technologie précise produit toujours un meilleur code — ce n'est pas discutable. Mais elle ne se transfère pas : change de stack et tu repars de zéro. La compréhension du flow de développement, de l'architecture et des principes, elle, se transfère intégralement. C'est ce qui permet de travailler dans un code que tu ne connais pas encore : le plan mode (étape 04) montre comment ce projet précis est agencé, et juger si une solution est la bonne, tu sais déjà le faire.