Développement d'applications web
Quand le difficile n'est pas l'écran mais le comportement : ce qui se passe sur une connexion lente, dans deux onglets ouverts, quand la même réservation est prise deux fois.
Ce que cela couvre
- Planification, réservation et disponibilités, fuseaux horaires et prévention des doubles réservations inclus
- Tableaux de bord dont les chiffres concordent avec les enregistrements
- Envoi, traitement et stockage de fichiers avec des limites et une validation sensées
- Intégrations avec agendas, prestataires de paiement, messagerie et comptabilité
- Traitements longs sortis du cycle de requête, avec progression visible et reprises
Quand c'est nécessaire
Quand le produit est le logiciel lui-même et non un site qui le décrit. Ou quand un outil interne est devenu la façon de travailler et ne peut plus être un projet secondaire.
Aussi quand une application fonctionne à dix utilisateurs et s'effondre à deux cents.
Problèmes fréquents dans les systèmes existants
- Des heures enregistrées sans fuseau. Au changement d'heure, les rendez-vous se décalent d'une heure et le client arrive au mauvais moment. Nous stockons chaque heure en UTC avec son fuseau et testons les dates de bascule.
- La disponibilité est vérifiée, puis enregistrée à part. Deux clics simultanés obtiennent le même créneau. Nous faisons refuser la seconde réservation par la base : la double réservation devient impossible, pas seulement improbable.
- Une erreur de validation efface le formulaire. La personne qui avait rédigé une longue demande abandonne. Nous conservons la saisie et indiquons précisément le champ à corriger.
- Des erreurs invisibles pour l'équipe. Une intégration s'arrête et personne ne s'en aperçoit avant la plainte d'un client. Nous journalisons les échecs et alertons une personne le jour même.
Ce que nous faisons
Nous identifions les opérations où l'exactitude compte et les sécurisons dans la base de données : contraintes et transactions plutôt que vérifications optimistes dans le code.
Chaque appel externe a un comportement défini en cas d'échec, une politique de reprise si nécessaire, et une trace consultable ensuite.
Déroulé de la mission
- Phase de cadrage sur la machine à états, les cas d'échec et les intégrations
- Développement par étapes, en commençant par l'opération sur laquelle l'entreprise ne peut pas se permettre d'erreur
- Des tests centrés sur les règles, pas sur un pourcentage de couverture
- Livraison avec les procédures d'exploitation des intégrations dont vous dépendez
Dites-nous ce que l'application doit réussir.
Les opérations qui ne peuvent pas échouer comptent plus que la liste des fonctions.