02 Notre méthode

Les bugs, vos clients les trouve en premier.

Chaque système a des défauts. La question est de savoir qui les découvre — une machine, avant la mise en production, ou un client payant au pire moment possible.

Démarrer un projet

La qualité est un processus, pas une phase

La qualité logicielle est généralement vendue comme un test final : on construit, puis on vérifie. Ce modèle échoue pour une raison simple — le temps que vous testiez, les erreurs coûteuses sont déjà ancrées dans l'architecture, et la pression pour livrer rend tout défaut découvert à ce stade fâcheux.

L'alternative consiste à rendre des catégories entières de bugs impossibles plutôt que de les traquer une par une. Un système de types qui rejette une valeur manquante avant que le code ne s'exécute. Des règles métier déclarées une seule fois à un seul endroit plutôt que ré-implémentées sur chaque écran. Des vérifications automatisées qui tournent à chaque changement, si bien que rien ne fusionne sans les avoir passées.

Il ne s'agit pas de perfection. Il s'agit de savoir où les défauts sont détectés. Un bug trouvé par un compilateur coûte des secondes. Trouvé en revue, des minutes. Trouvé en production par un client, il coûte un incident, des excuses, et une part de confiance qu'on ne récupère jamais.

TESTSBROKEN STOPS HERELIVE

Comment savoir si c'est votre problème

Chaque projet commence par un appel de cadrage
  • ↳ Vos clients signalent des bugs avant que votre équipe ne les remarque
  • ↳ Les mises en production sont stressantes et ont souvent lieu tard le soir
  • ↳ Le même bug revient des mois après avoir été corrigé
  • ↳ Personne n'a confiance pour modifier certaines parties du code
  • ↳ Tester signifie qu'une personne clique dans l'application à la main
  • ↳ Corriger une chose en casse régulièrement une autre

Comment nous y parvenons

TYPESTESTSREVIEWLIVEA CHANGE PASSES FOUR CHECKSCHEAPEST TO FIX ON THE LEFT
TypeScript strict
Le compilateur rejette des classes entières d'erreurs — valeurs nulles, structures incorrectes, cas oubliés — avant toute mise en ligne.
Ash Framework
Règles métier, permissions et validations déclarées une seule fois dans le domaine : impossible de les oublier à un endroit du code.
Tests et CI à chaque modification
Rien n'est fusionné sans validation. Les régressions sont détectées par des machines, pas par vos clients.

Ce que coûte l'inaction

01

La confiance se perd plus vite qu'elle ne se gagne

Les clients pardonnent une fonctionnalité manquante. Ils ne pardonnent pas de perdre leur travail, d'être facturés deux fois, ou un paiement qui échoue. Les défauts de fiabilité coûtent des clients dont vous n'entendrez jamais plus parler.

02

Chaque correction coûte plus cher que la précédente

Un défaut détecté par le compilateur ne coûte rien. Détecté en revue de code, il coûte peu. Détecté en production, il coûte un déploiement d'urgence, du travail perdu, et la réunion pour expliquer pourquoi.

03

L'équipe finit par avancer au ralenti

Dans une base de code sans filet de sécurité, chaque changement est un pari. Les développeurs ralentissent volontairement, parce que la prudence est leur seule protection.

04

Les régressions s'installent pour de bon

Sans vérifications automatisées, un bug corrigé aujourd'hui peut revenir discrètement dans trois mois. Les équipes finissent par corriger le même problème encore et encore, et appellent ça de la maintenance.

WITHOUT ITWITH ITCOST OVER TIME

Les questions qu'on nous pose

Tous ces tests, ce n'est pas plus lent et plus coûteux ?
C'est plus lent les premières semaines, et plus rapide toutes les semaines suivantes. Le coût des tests se paie une fois ; le coût de leur absence se paie à chaque changement, indéfiniment. Les équipes qui n'en ont pas n'avancent pas plus vite — elles avancent prudemment, ce qui ressemble à de la lenteur.
Vous testez tout ?
Non, et quiconque prétend le contraire essaie de vous vendre quelque chose. Nous testons lourdement là où l'échec coûte cher — l'argent, les données, l'authentification, tout ce qui est irréversible — et légèrement là où c'est cosmétique. Viser un pourcentage de couverture n'a jamais été la même chose qu'être en sécurité.
Qu'est-ce que TypeScript strict nous apporte concrètement ?
Il rend impossible à écrire toute une catégorie de bugs courants : valeurs manquantes, structures de données incorrectes, cas non gérés. Le compilateur les refuse avant même que le code ne s'exécute, ce qui veut dire qu'ils n'atteignent jamais un client.
Notre système existant n'a aucun test. Est-il trop tard ?
Non. L'approche pragmatique n'est pas d'ajouter des tests partout après coup — c'est d'en ajouter autour des parties qui cassent le plus souvent et de celles qui gèrent l'argent ou les données. Cela capte l'essentiel du bénéfice pour une fraction du travail.
Comment savoir si la qualité s'est vraiment améliorée ?
En mesurant des choses concrètes : la fréquence des échecs de mise en production, le temps nécessaire pour corriger un bug, le nombre de problèmes signalés par les clients plutôt que détectés en interne. Si ces chiffres ne bougent pas, le travail n'a servi à rien.

Les trois autres

Les bugs, vos clients les trouve en premier.

Dites-nous où ça bloque. Un appel court, une réponse honnête sur si nous sommes la bonne équipe, et un périmètre que vous pouvez chiffrer.

Démarrer un projet hello@elixiria.ma
enfrar