Deux applications en production. Deux ans de développement en solo. Des dizaines de décisions techniques, quelques bonnes, beaucoup de mauvaises au départ. Officio — gestion des arbitres de basketball — et MyKortex — dashboard opérationnel pour opticiens indépendants — m'ont appris plus que n'importe quel tutoriel.

Voici les cinq pièges dans lesquels je suis tombé, et comment les éviter si vous lancez votre propre projet solo.

Piège n°1 : Sous-estimer le périmètre métier

Quand j'ai démarré Officio, le brief tenait en une ligne : « Gérer les arbitres et leurs matchs. » Simple. Six semaines plus tard, le schéma de base de données comptait 34 tables.

Arbitres, clubs, championnats, divisions, saisons, désignations, conflits d'intérêt, indemnités kilométriques, niveaux de qualification, disponibilités, notifications, historiques... Chaque concept métier cache une dizaine de sous-concepts qu'on ne découvre qu'en creusant avec les vrais utilisateurs.

🛠️ La solution

Avant d'ouvrir votre éditeur, passez deux sessions de 2h avec l'utilisateur final à modéliser le domaine sur tableau blanc. Identifiez chaque entité, ses attributs, ses relations. Ce temps n'est jamais perdu.

Depuis, je commence chaque projet par un Domain-Driven Design léger : dictionnaire des termes métier, diagramme entité-relation, liste des cas d'usage triés par valeur.

Piège n°2 : Choisir une stack trop ambitieuse

Pour MyKortex, j'ai failli partir sur une architecture microservices. Docker, Kubernetes, event sourcing, API gateway... J'avais lu trop de posts LinkedIn sur la scalabilité.

J'ai finalement opté pour quelque chose d'ennuyeux : Vue.js + Laravel + MySQL sur un VPS. Monolithique, banal, pas impressionnant à raconter en soirée. Résultat : MyKortex est en production depuis 18 mois, gère 23 opticiens, et n'a pas connu une seule panne applicative.

📌 Règle d'or

Choisissez la stack la plus ennuyeuse qui résout votre problème. La complexité architecturale est un luxe que seules les équipes de 10+ ingénieurs peuvent se permettre.

Piège n°3 : Négliger l'authentification et les rôles

Sur MyKortex, j'ai ajouté la gestion des rôles — admin, opticien, technicien — à 60% du développement. Ce qui aurait pris 3 jours en début de projet m'a coûté deux semaines de refactoring.

// Ce qu'il NE FAUT PAS faire (vécu)
if ($user->email === 'admin@mykortex.com') {
    return $this->adminAction();
}

// Ce qu'il FAUT faire dès le jour 1
$this->authorize('admin-action', $resource);
// + Policy Laravel claire et centralisée

Depuis, le système d'auth est la première chose que je construis sur chaque projet. Modèle User, rôles, permissions, middleware — tout ça avant même la première page fonctionnelle.

Piège n°4 : Sous-estimer les exports

Dans les deux projets, les exports PDF et Excel ont été présentés comme des fonctionnalités secondaires. « On verra ça plus tard. » Ce sont devenues les fonctionnalités les plus utilisées.

Sur Officio, les responsables de championnat exportent les feuilles de désignation en PDF chaque semaine. Sur MyKortex, le rapport mensuel PDF est envoyé automatiquement aux franchiseurs. Sans ces exports, les apps seraient inutilisables en contexte pro.

Générer un PDF propre est nettement plus complexe qu'il n'y paraît. Mise en page, sauts de page, logos, tableaux... Comptez 3 à 5 jours pour un système d'export sérieux.

🛠️ La solution

Demandez systématiquement en phase découverte : « Dans votre métier, qu'est-ce que vous sortez de vos outils ? » Les besoins d'export émergent toujours. Mieux vaut les anticiper dès le début.

Piège n°5 : Pas de monitoring en production

C'est la leçon la plus chèrement acquise. Trois mois après le lancement d'Officio, la base de données a saturé ses connexions simultanées. Je l'ai appris par un SMS d'un utilisateur — pas par une alerte système.

Depuis ce jour, chaque app que je livre a un monitoring minimal en place dès le premier jour :

  • Uptime Robot — ping toutes les 5 minutes, alerte email + Telegram si le site tombe
  • Sentry — capture des erreurs JS et PHP en temps réel avec contexte complet
  • Logs structurés — chaque action critique loggée avec contexte utilisateur et horodatage
  • Alertes ressources — cron qui ping un webhook si CPU/disque dépasse 80%

Coût total : environ 4h de mise en place et 0€ de budget. Tous ces outils ont un plan gratuit suffisant pour un projet en démarrage.

Ce que ça m'a vraiment appris

Développer en solo ne signifie pas développer en amateur. Ça signifie être rigoureux sur les décisions prises avant de coder, parce qu'il n'y a personne pour rattraper les mauvais choix en code review.

Chacun de ces cinq pièges a une solution simple, accessible, et qui ne coûte rien d'autre que du temps et de la rigueur en phase de conception. L'expérience s'achète rarement à bon marché — mais avec un peu de chance, les erreurs des autres peuvent s'avérer moins coûteuses que les siennes.

Si vous démarrez un projet d'application métier et que vous voulez éviter ces erreurs dès le départ, parlons-en. Une heure de cadrage peut éviter des semaines de refactoring.

Articles connexes