Comment j'automatise mon workflow de développement web (et ce que je garde manuel)

J'ai passé trois mois à automatiser le mauvais bout de mon workflow. J'avais un pipeline de déploiement propre, des tests qui roulaient tout seuls, et je continuais quand même à me coucher à 1h du matin en train de fixer des trucs urgents. Le problème n'était pas dans mon code CI/CD. Il était dans ma tête, dans les décisions que je refusais de déléguer et celles que j'aurais dû garder pour moi.

Ça fait deux ans que je gère mes projets en solo, entre du freelance et mes side projects. J'ai fini par comprendre une chose : l'automatisation développement web ne sauve personne du burnout si elle attaque les mauvaises tâches. Certaines répétitions doivent disparaître de ton quotidien. D'autres, celles qui demandent ton jugement, doivent rester intactes, sinon tu perds la qualité qui justifie ton tarif ou ta réputation.

Ce que j'automatise sans hésiter

Les tests automatisés sont la première chose que j'ai mise en place sur chaque nouveau projet, et je ne reviendrai jamais en arrière. Avant, je testais manuellement chaque fonctionnalité avant un push, ce qui me prenait facilement 45 minutes par jour sur un projet de taille moyenne. Aujourd'hui, une suite de tests roule à chaque commit et me signale les régressions avant que je perde du temps à les chercher moi-même.

Le formatage du code, pareil. J'ai configuré Prettier et ESLint pour qu'ils tournent en pre-commit hook. Ça enlève un débat mental complètement stérile : est-ce que je mets des guillemets simples ou doubles, est-ce que j'indente à deux ou quatre espaces. Ce sont des décisions qui ne créent aucune valeur, elles ne font que consommer de l'énergie décisionnelle que je préfère garder pour autre chose.

Le déploiement, c'est le troisième morceau que j'ai automatisé complètement. J'ai un pipeline CI/CD sur GitHub Actions qui build, teste et déploie automatiquement dès qu'un commit passe sur la branche main. Avant ça, je faisais des déploiements manuels le vendredi soir (mauvaise idée, je sais) et je passais mon weekend à surveiller si le serveur tenait le coup. J'ai écrit un guide détaillé là-dessus pour les projets iOS, mais le principe reste identique peu importe la stack : automatiser le déploiement continu avec CI/CD enlève une source constante d'anxiété de ton quotidien.

J'automatise aussi :

• La génération de changelogs à partir des commits
• Les backups de base de données (quotidiens, sans exception)
• Les notifications Slack quand un déploiement échoue
• Le monitoring des erreurs en production avec des alertes automatiques

Chacune de ces tâches a un point commun : elle est répétitive, elle ne demande aucun jugement créatif, et l'erreur humaine y coûte plus cher que le temps d'automatisation initial.

Ce que je refuse de déléguer

Ici, je vais probablement décevoir les gens qui pensent qu'automatiser plus égale toujours mieux. Les décisions d'architecture, je les garde 100% manuelles. J'ai déjà vu des outils IA proposer des structures de dossiers ou des choix de base de données qui semblaient corrects sur le moment, mais qui créaient des dettes techniques énormes six mois plus tard.

La revue de code critique reste aussi entièrement manuelle chez moi, même quand je bosse seul. Je relis mon propre code le lendemain matin avant de le pousser en production, surtout sur les parties sensibles : authentification, paiements, gestion des données clients. Un linter automatique attrape les erreurs de style. Il n'attrape pas la logique métier fragile ou le edge case que t'as oublié parce que t'étais fatigué à 23h.

La relation client, c'est le troisième pilier que je garde humain à 100%. J'ai testé des chatbots pour filtrer les premières conversations avec des prospects. Résultat : deux clients potentiels sont partis parce que la réponse automatisée sonnait générique et impersonnelle. Ça m'a coûté cher pour apprendre cette leçon. J'en parle plus en détail dans mon article sur les erreurs d'acquisition qui ont failli tuer mon freelancing, mais le résumé, c'est que les clients sentent quand ils parlent à un système plutôt qu'à une personne, et ça détruit la confiance avant même le premier contrat.

L'automatisation est excellente pour éliminer la répétition. Elle est mauvaise pour remplacer le contexte, l'intuition, et la nuance qu'un client attend d'une vraie relation professionnelle.

L'équilibre que j'ai raté au début

Ma première erreur, c'était de croire que plus j'automatisais, moins j'aurais de charge mentale. Faux. J'ai fini avec un tas de scripts, de webhooks et de pipelines que je devais moi-même maintenir. Automatiser une tâche crée une nouvelle responsabilité : celle de surveiller que l'automatisation fonctionne encore.

J'ai eu un cas concret l'année passée. Mon pipeline CI/CD s'est mis à échouer silencieusement pendant trois jours parce qu'une dépendance avait changé de version. Je ne l'ai su qu'en recevant un email de client demandant pourquoi son site n'était pas à jour. L'automatisation m'avait donné une fausse sensation de sécurité, et j'avais arrêté de vérifier manuellement ce qui, avant, me forçait à rester attentif.

La leçon que j'aurais aimé recevoir plus tôt : automatise ce qui est répétitif et sans enjeu, mais garde un rituel manuel léger pour vérifier que tout roule. Chez moi, ça veut dire un coup d'œil quotidien de dix minutes sur mes dashboards de monitoring, pas plus. Ce n'est pas glamour, mais ça évite les surprises coûteuses.

Le burnout chez les développeurs vient rarement du code lui-même. Il vient de la surcharge invisible : trop de décisions à prendre, trop de contextes à switcher, trop de petites tâches qui grugent l'attention sans jamais s'arrêter. J'ai documenté cette dynamique plus en détail dans mon article sur les pièges invisibles du travail en isolement, et un des points centraux, c'est justement cette confusion entre productivité et charge cognitive réduite. Ce ne sont pas la même chose.

Comment je décide quoi automatiser

J'ai fini par établir une règle simple que j'applique à chaque nouvelle tâche répétitive dans mon workflow. Je me pose deux questions : est-ce que cette tâche demande un jugement contextuel, et est-ce que l'erreur ici coûte cher humainement (relation, confiance) ou juste techniquement (bug, downtime) ?

Si l'erreur est purement technique et récupérable, j'automatise sans réfléchir longtemps. Un test qui échoue, un déploiement qui roll back automatiquement, un format de code incohérent : ce sont des erreurs sans conséquence émotionnelle, donc parfaites à déléguer à une machine.

Si l'erreur touche une relation humaine ou une décision structurante, je garde le contrôle. Un client qui reçoit une réponse robotique, une architecture bâclée qui va coûter des mois de refactoring, une revue de code qui laisse passer une faille de sécurité : ce sont des erreurs où le coût dépasse largement le temps économisé par l'automatisation.

Cette grille de décision, je la note aussi dans mon carnet de bord technique, où je garde une trace de chaque décision d'automatisation prise et pourquoi. Si le sujet t'intéresse, j'explique ce que je note chaque jour dans mon carnet de bord et comment ça m'aide à revoir mes choix six mois plus tard sans tout reconstruire de mémoire.

Un autre angle que j'ai découvert tard : l'automatisation ne se limite pas au code. Si tu gères le SEO de tes projets en parallèle du développement, tu tombes vite dans le même piège de surcharge mentale, entre l'audit de mots-clés, le suivi de positions et la génération de contenu. C'est exactement le genre de tâche répétitive qui gagne à être automatisée plutôt que faite à la main chaque semaine. Gridar, un outil SEO bilingue FR-CA, automatise justement l'audit, le suivi de positions et la génération d'articles pour les PME québécoises, ce qui m'a permis de retirer une partie de cette charge de mon horaire hebdomadaire sans sacrifier la qualité du contenu publié.

Chez TokamDarius, je continue d'ajuster ce curseur entre automatisation et contrôle manuel presque chaque mois. Aucun workflow n'est figé, et c'est normal. Un projet qui grossit change ce qui mérite d'être automatisé, et un client qui devient récurrent change ce qui mérite un contact humain plutôt qu'un template.

Si tu commences aujourd'hui à réviser ton propre workflow, ne pars pas en automatisant tout ce qui te tombe sous la main. Prends une seule tâche répétitive qui te frustre en ce moment, applique la question du coût de l'erreur, et automatise-la cette semaine. Pas les dix autres. Une seule. Tu verras l'impact réel avant de te lancer dans le reste, et tu éviteras l'erreur que j'ai faite en voulant tout automatiser d'un coup sans jamais mesurer si ça réduisait vraiment ma charge mentale ou si ça la déplaçait ailleurs.

---

À lire aussi

• Pivoter un produit numérique : comment j'ai su qu'il fallait changer de cap
• Développeur solo : les pièges invisibles du travail en isolement
• Mon carnet de bord technique : ce que j'y note chaque jour