Pourquoi cette app
La question n'est pas quel est le chiffre, mais d'où il vient.
La plupart des calculateurs de vol ont abandonné le devis de masse et centrage, ou ne l'ont jamais eu. Or brûler du carburant déplace le centre de gravité le long d'une courbe, pas d'une droite : vérifier seulement le début et la fin du vol peut manquer un dépassement au milieu, alors que c'est précisément ce que demandent les standards, dans toutes les phases du vol.
Deuxième parti pris : chaque résultat se déplie en dérivation complète. Les règles de calcul mental sont utiles et recommandées, mais aucune application ne montre de combien le raccourci tombe à côté. Isogonic affiche l'écart.
Troisième parti pris, le plus coûteux : la justesse est le produit. Chaque cas de la campagne de non-régression encode une erreur de calcul qu'une application concurrente a réellement livrée et qu'un pilote a signalée dans un avis. Un pilote qui trouve une erreur au sol ne fait plus confiance en vol.
Les défis techniques
Un résultat absurde, imprimé comme un fait.
Les constantes atmosphériques, dérivées et jamais recopiées. Les formes décimales publiées un peu partout sont arrondies à des rangs différents selon les sources, ce qui les rend mutuellement incohérentes à partir de la cinquième décimale. L'une des valeurs les plus reprises sur le web est même fausse. Les constantes sont donc dérivées dans le code plutôt que transcrites, et un test vérifie que les conditions standard au niveau de la mer donnent exactement zéro, sous trois formulations différentes. C'est exactement ce que rate une application concurrente dont les avis signalent un résultat non nul dans ce cas.
Le bug qui affichait une altitude densité de moins cent soixante-seize mille pieds. Le sélecteur était sur une unité de pression, la valeur saisie était dans l'autre. L'arithmétique était juste, l'entrée était absurde, et le résultat s'affichait en très gros caractères comme un fait établi. Chaque champ déclare désormais sa plage, volontairement large pour ne rien refuser de légitime, avec un message qui nomme l'erreur probable plutôt que de dire « valeur invalide ».
Deux rejets d'Apple pour plantage. En version publiée, toute erreur JavaScript non rattrapée est fatale et le processus s'arrête : c'est cette asymétrie avec le mode développement qui explique qu'une application passe tous les tests chez son auteur et se fasse refuser pour crash. Une barrière d'erreur a été posée par écran et une à la racine. Il a fallu en plus blinder les tracés, parce qu'une valeur non numérique dans des données de dessin ne lève aucune exception : elle atteint la couche vectorielle et fait tomber le côté natif, là où aucune barrière ne peut rattraper quoi que ce soit.
La cause racine du second rejet, et ce qu'elle a appris sur les tests. Un mémo de calcul ne dépendait que des valeurs saisies. Or changer d'avion change la liste des champs, pas seulement leur contenu : un modèle a deux soutes, un autre une seule, et le rendu mourait sur une clé absente. Le test écrit ensuite enregistre chaque rendu et pas seulement l'état stabilisé, parce qu'une première version qui ne vérifiait que l'état final passait tranquillement sur le code cassé.
Le centrage calculé en espace moment. Quand le carburant se consume, le centre de gravité décrit un segment droit dans le repère poids-moment, mais une hyperbole dans le repère poids-centrage. Tout le moteur travaille donc en moments, où la combustion est un simple segment et où le test d'appartenance à l'enveloppe redevient exact au lieu d'être approché.
L'attente, simulée pas à pas plutôt que résolue. Le modèle est délibérément littéral : on fait voler l'appareil dans le circuit par petits pas de temps en ajoutant le vecteur vent à chaque pas. Cela reproduit la déformation réelle, y compris la dérive accumulée pendant les virages, sans cas particuliers et sans rien qui puisse être subtilement faux.
Capmedia Digital