Le revenu s'arrête avec le système
Si vos clients transigent via votre logiciel, chaque minute d'interruption est un revenu perdu — et cela frappe le plus fort pendant les pics d'activité, ceux qui rapportent le plus.
04 Notre méthode
Le jour où ça tombe c'est le jour où ça compte.
Les pannes n'arrivent presque jamais au bon moment. La disponibilité, c'est la différence entre un problème que vos ingénieurs règlent discrètement et un problème que vos clients annoncent à votre place.
Démarrer un projetLa panne est normale. L'interruption de service est un choix.
Les choses finissent par tomber en panne. Le matériel meurt, les réseaux se partitionnent, les prestataires tiers ont de mauvais jours, et des chemins de code que personne n'avait anticipés finissent par s'exécuter. Aucune précaution ne rend la panne impossible — la disponibilité, ce n'est pas l'empêcher, c'est décider de ce qui se passe ensuite.
Dans un système mal conçu, une seule panne fait tout tomber, parce que chaque partie dépend de la bonne santé de toutes les autres. Dans un système bien conçu, la panne est contenue : l'élément touché redémarre ou est contourné, et le reste du système continue de servir des clients qui n'apprennent jamais que quelque chose a cloché.
L'autre moitié du problème, c'est de le savoir. Beaucoup d'équipes découvrent que leur système est en panne quand un client le leur annonce. La supervision et l'alerte dès le premier jour changent la donne — la dégradation est repérée pendant qu'elle est encore mineure, et vous en entendez parler par nous, avec un correctif déjà en cours.
Comment savoir si c'est votre problème
Chaque projet commence par un appel de cadrage- ↳ Vous avez appris une panne par un client
- ↳ Un seul composant défaillant entraîne tout le système avec lui
- ↳ Déployer exige de mettre le site hors ligne
- ↳ Il n'y a pas d'alerte, ou les alertes sont ignorées
- ↳ La reprise dépend de la disponibilité d'une seule personne
- ↳ Personne ne sait combien de temps prendrait une restauration depuis la sauvegarde
Comment nous y parvenons
- Supervision OTP
- Quand un processus tombe, son superviseur le redémarre en quelques millisecondes. Le reste du système ne s'en aperçoit pas.
- Oban
- Les tâches de fond sont stockées dans Postgres au sein de votre transaction. Une panne en plein paiement déclenche une reprise, pas une perte.
- Supervision dès le premier jour
- C'est nous qui vous signalons une dégradation, correctif déjà en cours — pas un client mécontent.
Ce que coûte l'inaction
L'atteinte à la réputation survit à la panne
L'incident dure une heure. L'impression que votre produit n'est pas fiable dure bien plus longtemps, et elle se propage par des canaux que vous ne contrôlez pas.
Sans plan, la reprise prend bien plus de temps
Les équipes qui n'ont jamais testé une restauration découvrent pendant la panne que la sauvegarde était incomplète, ou que personne n'a les accès. Improviser transforme des minutes en heures.
Les pannes silencieuses sont les pires
Sans supervision, la dégradation passe inaperçue jusqu'à devenir sévère. Les problèmes qui s'installent lentement — un disque qui se remplit, un pool de connexions qui fuit — coûtent peu à corriger tôt et cher une fois qu'ils mettent le système à terre.
Les questions qu'on nous pose
- Avons-nous besoin de 99.99% de disponibilité ?
- Presque certainement pas, et courir après ce chiffre coûte cher. Ce qui compte, c'est d'aligner l'objectif sur le métier : un système qui encaisse des paiements en continu n'a pas les mêmes besoins qu'un outil interne utilisé aux heures de bureau. Nous préférons fixer l'objectif dont vous avez réellement besoin plutôt que de vous vendre un chiffre.
- Que se passe-t-il quand quelque chose casse vraiment ?
- Les composants supervisés redémarrent automatiquement en quelques millisecondes, donc la plupart des pannes sont absorbées sans que personne ne s'en aperçoive. Pour tout ce qui est plus important, l'alerte nous atteint directement — vous entendez parler de nous avec un correctif déjà en cours, pas d'un client mécontent.
- La haute disponibilité signifie-t-elle payer une infrastructure en double ?
- Pas nécessairement. Une grande partie de la résilience vient de la conception plutôt que du matériel : pannes contenues, tâches de fond capables d'être rejouées sans risque, et une couche de cache devant votre application. La redondance aide, mais ce n'est ni le premier ni le levier le moins cher.
- Pouvez-vous déployer sans mettre le site hors ligne ?
- Oui. Les mises en production se déploient progressivement, l'ancienne version continuant à servir jusqu'à ce que la nouvelle soit vérifiée saine, et revenir en arrière est une opération normale, pas une urgence. Un déploiement ne devrait jamais exiger de fenêtre de maintenance.
- Comment savez-vous que le système est en bonne santé ?
- Des métriques, des logs et un suivi des erreurs configurés dès le départ, avec des alertes sur ce qui annonce un problème plutôt que sur ce qui se contente de le confirmer. Quand quelque chose casse, la question est où — pas si.
Le jour où ça tombe c'est le jour où ça compte.
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