KISS ou Mourir : Pourquoi les Ingénieurs Seniors Échouent dans les Startups

Ma première startup a été un échec, et plusieurs startups voisines ont également échoué. Nous avions : 100 000 $ en crédits GCP, un ingénieur fondateur qui avait construit des systèmes en entreprise, et une stratégie de mise sur le marché. Et nous avons échoué, non pas parce que nous l'avons mal construit, mais parce que nous l'avons bien construit. C'était le problème.

Pendant que nous passions du temps à lutter avec ce qui semblait être une stack technologique "non optimale", nous avons perdu la chose la plus importante : du temps, de l'élan, et stratégiquement une opportunité.

Cette histoire ne parle pas de personnes sans bon sens. J'avais du bon sens, et nous savions que nous devions garder les choses simples. Mais quand votre modèle mental ne correspond pas à la situation, tout votre bon sens disparaît. Vous prenez des décisions "correctes" qui vous tuent.

Ce n'est pas non plus une histoire de mauvaise ingénierie. C'est plutôt comment la bonne ingénierie tue les startups. Comment l'expérience même qui vous rend senior devient votre plus grand handicap. Comment "bien faire les choses" ou même "faire les choses simplement" est souvent une erreur.

Cet article présente des modèles mentaux pour vous aider à prendre les bonnes décisions et éviter les erreurs que j'ai commises.

:::tip À qui s'adresse cet article : aux ingénieurs seniors qui démarrent ou rejoignent des startups en phase initiale. Si vous avez passé plus de 5 ans dans l'entreprise ou la Big Tech, ceci est votre avertissement.

:::

\

Modèle Mental #1 - L'infrastructure "gratuite" est la plus coûteuse

100 000 $ en crédits GCP semble être un cadeau, mais c'est un piège. Cela vous pousse vers la sur-ingénierie parce que "c'est déjà payé". Vous obtenez des instances de calcul, des équilibreurs de charge, des registres de conteneurs et des outils d'entreprise qui nécessitent une configuration d'entreprise. Ce dont vous avez besoin ? Un bouton "push to deploy".

Bien sûr, vous pouvez créer des workflows "déployer depuis GitHub vers VM" sur GCP/AWS/Azure. Certains produits s'en approchent. Mais cela nécessite des étapes supplémentaires : configurer Cloud Build, définir des rôles IAM, écrire des scripts de déploiement, gérer des secrets et configurer des contrôles de santé. Vous perdez du temps à construire une infrastructure de déploiement avant de déployer les produits réels.

Pendant ce temps, des plateformes comme Railway ou Fly.io vous donnent ce dont les startups ont réellement besoin : une VM persistante avec déploiement direct depuis GitHub. Aussi simple que possible : vous poussez votre code, et il se déploie. Une VM prête à l'emploi avec variables d'environnement, SSL, équilibreurs de charge, logs, etc. Ce n'est pas "gratuit", mais c'est prêt.

Les crédits gratuits vous poussent vers la sur-ingénierie parce que "c'est déjà payé". Vous vous convainquez que vous économisez de l'argent tout en dépensant votre ressource la plus précieuse : le temps.

\

Modèle Mental #2 - "Minimal" <> "Simple"

Le principe KISS traditionnel nous dit de garder notre logiciel simple. Mais dans les startups, c'est la mauvaise cible. Vous ne devriez pas garder votre LOGICIEL simple ; vous devriez garder vos SOLUTIONS simples.

La vraie simplicité devrait être mesurée par l'effort total, pas par la complexité du code :

Effort Total = Construction Initiale + Maintenance + Débogage + Ajout de Fonctionnalités + Mises à jour de Sécurité + Changements d'Échelle

Quand vous construisez à partir de zéro, vous possédez tout cela pour toujours. Quand vous utilisez un service, la plupart de ces éléments deviennent nuls. Le service tiers "gonflé" est en fait la solution simple car il minimise l'effort total.

Mon exemple OAuth

Notre ingénieur fondateur a décidé de construire OAuth à partir de zéro au lieu d'utiliser une "bibliothèque inconnue". Une semaine plus tard, il a soumis une PR : implémentation propre d'OAuth avec tokens JWT, rotation des tokens de rafraîchissement, gestion de session et contrôle d'accès basé sur les rôles. Pas de dépendances, pas de verrouillage fournisseur, juste du code que nous contrôlions.

Je n'ai pas refusé la PR. Et c'était une erreur. Jeter une semaine de travail aurait écrasé le moral. Mais cela crée une complexité de code et nous met sur les mauvais rails. De plus, ne pas discuter de l'approche au préalable était notre vraie erreur. Nous avons laissé la fierté d'ingénierie prendre une décision stratégique.

Ensuite, un client a eu besoin de Microsoft OAuth et Google OAuth. L'implémentation personnalisée signifiait des jours de refactoring, de rotation des tokens de rafraîchissement, de cas limites, de RBA et d'autres choses. Chaque ajout "simple" nécessitait une compréhension profonde de notre authentification personnalisée. Chaque mise à jour de sécurité était à nous d'implémenter. Chaque nouvelle exigence était à nous de coder.

Principes

Erreur classique d'ingénieur senior : optimiser pour le contrôle plutôt que pour les résultats. Dans les startups, la réalité exige d'inverser complètement la façon de penser des ingénieurs seniors :

1. ARRÊTEZ de penser : "Ce n'est que quelques jours de codage" \n COMMENCEZ à penser : "Ce sont quelques jours à NE PAS coder mon produit réel"
2. ARRÊTEZ de penser : "Je peux construire cela simplement" \n COMMENCEZ à penser : "Je peux résoudre cela simplement en ne construisant pas"
3. ARRÊTEZ de penser : "Les services tiers ajoutent de la complexité" \n COMMENCEZ à penser : "Les services tiers absorbent la complexité"

\

\

Modèle Mental #3 - Les choix de confort

Nous avons choisi Angular parce que notre ingénieur fondateur le connaissait profondément. Décision intelligente, non ? Utilisez vos forces, livrez du code de qualité. Le framework était bien, MAIS le problème était son écosystème.

Le piège de l'écosystème

Angular est excellent et notre ingénieur pouvait tout construire avec.

Mais "tout" prenait du temps juste pour commencer. Configurer le déploiement, l'authentification et les composants UI de base signifiait une configuration sans fin avant d'écrire une seule fonctionnalité. Pendant que nous déboguions les thèmes Angular Material, les concurrents peuvent (et vont) utiliser Next.js + Vercel et intégraient déjà des utilisateurs.

Comparez simplement cela au chemin Next.js + Vercel : déployez une application squelette avec npx create-next-app le premier jour, ajoutez l'authentification Clerk et les composants shadcn/ui, livrez des fonctionnalités réelles dès le premier jour. Même destination, voyage complètement différent.

Pourquoi cela se produit-il ?

La différence n'est pas la qualité du framework, c'est l'optimisation de l'écosystème. Next.js/React est entouré de startups financées par du capital-risque qui construisent des outils pour d'autres startups :

• UI : shadcn/ui - copier, coller, livrer
• Auth : Clerk/Supabase - configurer en minutes
• Déploiement : Vercel - git push équivaut à la production
• Tout le reste : Si les startups en ont besoin, quelqu'un a construit un service

L'écosystème d'Angular sert les entreprises : puissant, flexible, infiniment personnalisable. Parfait(?) pour des équipes de 50 personnes et un poison pour des équipes de 3.

\

Modèle Mental #4 - Construire le cœur, louer le contexte

Mais même avec les bons outils, il y a un dernier piège : la compulsion de construire des choses parce que vous le pouvez, pas parce que vous le devriez. Ce piège tue les équipes techniquement fortes et plus de startups que nous pouvons imaginer : construire des choses que personne n'a demandées parce que vous le pouvez, pas parce que vous le devriez.

Nous avons passé au moins un mois au total sur des fonctionnalités dont personne n'avait besoin. OAuth personnalisé alors qu'Auth0 existait. Une file d'attente de jobs basée sur Postgres alors que Redis + Celery existaient. Terraform dès le premier jour, alors que la console fonctionnait bien. Chaque décision semblait productive, mais chacune était un sabotage pour affronter de vrais défis comme parler aux clients ou faire d'autres développements clients.

Le modèle est simple : si les clients ne vous choisiront pas pour cela, ne le construisez pas.

Ma règle des 50 $

Si un SaaS coûte moins de 50 $/mois, vous ne pouvez pas vous permettre de le construire. Votre temps est trop cher.

Construire un OAuth personnalisé prend 1-2 semaines au total en maintenance et en ajoutant différents fournisseurs OAuth. Aux taux de combustion des startups, c'est 5 000-15 000 $ en temps d'ingénierie, ou en temps d'opportunité perdue. Auth0 est gratuit jusqu'à 25 000 utilisateurs actifs, puis 35 $/mois. Vous pourriez payer Auth0 pendant 35 ans avec ce qu'il coûte de le construire une fois.

Donc, ce n'est pas une question d'argent mais de priorités et de coût d'opportunité.

Exception

À mon avis, construisez uniquement si vous ne pouvez pas en apprendre sur les utilisateurs sans cela.  Un exemple simple est lorsque vous devez tester si les utilisateurs paieront pour des rapports générés par IA. Construisez la version la plus simple qui prouve la demande. Et tout le reste essaie de glisser. Oui, sautez l'infrastructure, sautez "bien faire les choses", sautez les meilleures pratiques qui ne livrent pas de fonctionnalités, sautez les tests. Encore une fois, soyez aussi paresseux que possible en écrivant du code.

Ce que j'utilise réellement

• Auth : Clerk (React-native, meilleur DX) ou Auth0 (orienté B2B, prêt pour l'entreprise)
• Email : Resend (d'abord pour les développeurs) ou SendGrid (éprouvé au combat)
• Analytique : PostHog (gratuit jusqu'à l'échelle)
• Surveillance : Sentry (imbattable pour les erreurs)
• Hébergement : Cloudflare ou Vercel (si tout sur Next.js)

Ce ne sont pas des recommandations mais mes propres choix optimisés pour la vitesse. Je suppose que votre stack sera différente mais ce principe ne le sera pas.

\

\

Conclusion

Les LLM ont banalisé la construction. N'importe quel junior avec Claude peut créer ce système d'authentification personnalisé dont vous êtes si fier. Votre valeur n'est plus dans ce que vous pouvez construire, MAIS dans ce que vous savez ne pas construire.

Le leadership est la capacité de séparer les signaux du bruit. La vraie séniorité signifie avoir la discipline d'ignorer 90% de ce que vous savez et de livrer la solution d'aujourd'hui, pas l'architecture de demain.