Une petite équipe présente un avantage enviable et un risque silencieux. L’avantage est la rapidité : peu de personnes, peu de bureaucratie, des décisions rapides. Le risque est que chaque mauvais choix pèse davantage, car il n’y a plus personne pour éteindre les incendies qu’il provoque.
Sur le backend, cela est particulièrement vrai. C'est la couche où résident la logique, les données et la fiabilité du produit. Une belle interface sur un backend fragile est un château sur le sable. Et quand vous avez deux, trois, cinq développeurs, vous ne pouvez pas prendre en charge une architecture qui nécessite un bataillon pour fonctionner.
Ce texte rassemble les bonnes pratiques backend conçues spécifiquement pour les petites équipes. Ici, la règle n'est pas ce que font les grandes entreprises, c'est ce qui a du sens lorsque chaque heure d'ingénierie est précieuse et qu'il n'y a pas de place pour une complexité gratuite.
La règle d'or : la simplicité est un avantage concurrentiel
Dans une petite équipe, la complexité est l’ennemi. Chaque élément d'architecture supplémentaire est une chose de plus à comprendre, à maintenir, à surveiller et à corriger dès l'aube. Et vous n’avez que quelques personnes pour faire tout cela.
La première bonne pratique est donc de résister à la tentation d’imiter l’architecture des géants. Microservices, messagerie complexe, orchestration de conteneurs, tout cela résout de vrais problèmes pour les grandes entreprises, et crée de nouveaux problèmes pour les petites équipes. Un bon monolithe bien organisé amène une startup bien plus loin que la plupart ne l’admettent.
La question à se poser face à chaque choix technique : est-ce que cela résout un problème que j'ai aujourd'hui, ou que j'imagine avoir un jour ? Une petite équipe ne peut pas payer pour la seconde.
Choisissez une technologie ennuyeuse et familière
Il y a du charme à adopter le nouveau langage, la banque tendance, le cadre qui est au sommet. Dans une petite équipe, ce charme est un piège.
La technologie consolidée dispose d'une documentation, d'une communauté, de personnes disponibles sur le marché et de réponses toutes prêtes aux problèmes que vous rencontrerez. Les nouvelles technologies n’ont pas grand-chose de tout cela, et lorsque vous tombez en panne, elles se bloquent d’elles-mêmes. Pour une grande équipe, expérimenter ne coûte pas cher. Pour une équipe de trois personnes, chaque heure passée à combattre un outil immature est une heure non consacrée au produit.
Choisissez la base de données que vous connaissez. Choisissez la langue dans laquelle l'équipe est productive. L'innovation de votre startup doit résider dans le produit et le problème qu'il résout, et non dans la pile technologique. Une technologie ennuyeuse libère de l’énergie pour ce qui compte.
Des bonnes pratiques adaptées au budget d'une petite équipe
Certaines pratiques donnent un retour sur effort disproportionné. Voici ceux que je privilégierais :
- Base de données bien modélisée : la plupart des problèmes de backend proviennent de données mal structurées. Investir du temps dans le modèle de données au début permet d'économiser des mois plus tard. Ce sont les fondations, refaire les fondations avec la maison encore debout est pénible.
- Configuration hors code : secrets, clés et paramètres d'environnement jamais à l'intérieur du référentiel. Cela évite les fuites classiques et facilite l’exécution du même code dans différents environnements.
- Journaux décents : vous n'avez pas d'équipe d'exploitation pour enquêter sur les problèmes, le système doit donc vous informer de ce qui se passe. Une journalisation bien conçue est votre seul détective en cas de panne.
- Migrations de bases de données versionnées : les modifications de la structure des données doivent être traçables et réversibles. Changer un siège à la main, directement en production, c'est comme conduire sans ceinture.
- Gestion explicite des erreurs : décidez de ce qui se passe en cas d'échec. Une erreur avalée en silence est le type de bug qui n’apparaît que lorsqu’un client se plaint.
Aucune de ces pratiques ne nécessite des outils coûteux ou des connaissances exotiques. Ils nécessitent de la discipline, qui est à la fois la ressource la moins chère et la plus rare.
Automatisez rapidement ce que vous feriez de mal
Les petites équipes travaillent sous pression, et la pression produit des erreurs humaines. La défense consiste à automatiser ce qui peut l’être, notamment le déploiement et les tests.
Il n’est pas nécessaire que ce soit sophistiqué. Un processus de déploiement automatisé, même simple, évite l'erreur de télécharger une mauvaise version à onze heures du soir. Certains tests automatisés sur les chemins critiques, la connexion, le paiement, le flux principal, empêchent une solution rapide de casser quelque chose d'important sans que personne ne s'en aperçoive.
L’objectif n’est pas une couverture parfaite des tests, ce qui est un luxe pour une grande équipe. Il s'agit de protéger ce qui, en cas de panne, nuit à la trésorerie ou à la confiance du client. Ici, l’automatisation n’est pas une sophistication ; C'est un filet de sécurité pour les gens qui vont faire des erreurs parce qu'ils sont humains et qu'ils fuient.
Réflexion critique : une dette technique qui a du sens
Il existe un discours puriste qui condamne toute dette technique. Dans une petite équipe, ce discours est irréaliste. Vous prendrez des raccourcis, et vous avez raison d’en prendre. Le problème n’est pas la dette ; c'est la dette invisible et oubliée.
La dette technique consciente est un outil commercial. Vous décidez de faire quelque chose de simple maintenant, sachant que vous devrez y revenir plus tard, pour apporter de la valeur plus rapidement. C'est légitime. Ce qui tue, c'est la dette que personne n'a enregistrée, dont personne ne se souvient et qui explose au pire moment, sans prévenir.
La maturité, c'est choisir où prendre des raccourcis et où ne pas le faire. Raccourci sur la fonctionnalité secondaire, très bien. Raccourci en matière de sécurité des données, de contrôle d'accès, de traitement des données personnelles sous LGPD, alors le raccourci est une bombe. Savoir distinguer les uns des autres est ce qui différencie la petite équipe qui survit de celle qui implose.
Ce qui reste
Le backend pour une petite équipe est un exercice de concentration. Il ne s’agit pas de faire la chose la plus sophistiquée, il s’agit d’en faire assez, enfin, dans ce qui compte, et de résister à tout le reste.
Simplicité, technologie connue, fondamentaux solides, automatisation de l'essentiel et dette technique consciente. Ces cinq idées amènent une petite équipe étonnamment loin. La plupart des problèmes que je vois ne viennent pas d’un manque de capacités techniques, mais d’une trop grande ambition architecturale, trop tôt.
Si vous dirigez une équipe réduite et que vous prenez des décisions qui vous pèseront pendant des années, cela vaut la peine de bien réfléchir avant de vous engager dans la complexité. Sur le blog, il y a d'autres textes sur l'architecture, l'évolutivité et le produit qui parlent de celui-ci.
A lire aussi
- Cache dans les applications : guide rapide des bonnes pratiques (et des erreurs qu'il cache) -Architecture d'application - Principes fondamentaux des erreurs courantes -Backend As A Service - Bonnes pratiques pour les entreprises -Backend As A Service - Bonnes pratiques pour les débutants -Backend pour les applications : architecture, technologies et bonnes pratiques
- Sécurité dans les applications mobiles : architecture pour petites équipes