starLOG

Tout pilote qui vole avec un iPad connaît la situation : les cartes à l’écran, et le log de navigation sur une feuille pliée coincée à côté des manettes. L’application de cartes occupe l’écran. C’est le log de navigation qu’on sacrifie.

starLOG est conçu pour l’espace qui reste.

Pensé pour l’autre moitié de l’écran

La plupart des applications cockpit supposent qu’elles sont la seule chose que vous regardez. starLOG suppose l’inverse. Il embarque trois paliers de largeur, et non un compromis responsive — une mise en page large lorsqu’il dispose de l’écran, une intermédiaire, et une mise en page compacte réellement différente qui prend le relais en dessous de 500 points : la taille d’un panneau Slide Over ou du côté étroit d’un Split View.

La version compacte n’est pas la large comprimée. Elle utilise son propre schéma de tableau, avec ses colonnes, ses largeurs et son empilement ; l’en-tête de route se replie sur une seule ligne portant date, numéro de vol, route et source de position ; le type et l’immatriculation s’effacent ; et chaque ligne du log tient toujours les valeurs prévues et réelles en 32 à 36 points de hauteur. Chaque colonne et chaque champ porte une priorité déclarée : ce qui disparaît quand la fenêtre se resserre est une décision, pas un accident.

Vos cartes restent en pleine taille. Le log reste un tableau de travail, pas un aperçu.

Natif, au plus près du matériel, sans compromis

starLOG est écrit intégralement en Swift et SwiftUI, réparti sur dix-neuf paquets Swift locaux — aucun runtime multiplateforme, aucune vue web embarquée, aucun pont JavaScript. Ce n’est pas un argument de pureté, c’est ce qui rend le reste possible :

• La carte de route se dessine elle-même. Traits de côte, graticule, arcs de grand cercle, cercles de déroutement ETOPS et étiquettes de points sont rendus directement dans un Canvas SwiftUI, à partir d’un trait de côte vectoriel de 76 Ko et d’un répertoire de 885 aérodromes embarqués. Aucun serveur de tuiles, aucun téléchargement, aucun cache à préchauffer — cela fonctionne au FL390 au-dessus du Pacifique exactement comme au sol, et l’antiméridien se franchit sans couture.
• Un vrai globe 3D, hors ligne. NASA Blue Marble le jour, Black Marble la nuit, embarqués sur l’appareil, avec un véritable terminateur jour/nuit recalculé chaque minute — accéléré par le matériel sur iPad comme sur Mac, sans une seule tuile à télécharger.
• La position exploite le matériel correctement. GNSS multi-constellation via CoreLocation, avec un chien de garde qui relance la puce lorsqu’elle décroche, des géorepères autour des points à venir pour que le suivi survive à un arrêt forcé, et une cadence délibérée de 1 Hz pour ne noyer ni le moteur de suivi ni l’interface.
• La liaison entre appareils est la liaison matérielle. MultipeerConnectivity chiffré — Wi-Fi et Bluetooth pair à pair — et non un aller-retour cloud déguisé en outil de cockpit.
• Le vol vit sur l’écran verrouillé. Une Live Activity porte le prochain point avec sa distance et son ETA, l’avancement sur la route, le niveau courant, l’écart carburant par rapport au plan et l’ETA destination sur l’écran verrouillé et dans la Dynamic Island. Un coup d’œil ne coûte rien.
• L’interface utilise ce que l’OS propose, y compris le liquid glass sur les versions qui en disposent, avec un repli matériau propre sur les autres.

Tout se passe sur l’appareil. Aucun backend, aucun saut de télémétrie, aucun SDK d’analytique, aucune requête qui doive aboutir pour que l’app serve à quelque chose — et rien de votre vol ne sort de vos mains.

Adaptatif à ce que produit votre système de préparation des vols

Le format canonique est ARINC 633 — la norme d’échange de plans de vol du secteur — et starLOG le lit nativement, dans sa version 4 actuelle avec espace de noms comme dans le dialecte plus ancien, transcodant l’un vers l’autre champ à champ, ETOPS, reclairance et step climbs compris.

Mais toutes les compagnies n’émettent pas du 633 propre, alors starLOG va chercher les autres :

• Les conteneurs PFRShared et EFF s’importent directement — l’archive est ouverte, les sommes de contrôle de son manifeste vérifiées, le document de plan de vol localisé dans le catalogue et décodé, entièrement dans l’app.
• Les formats opérateurs arrivent sous forme de paquets de transcodage — une description installable et autonome de la mise en page OFP d’une compagnie : où trouver ses tableaux, comment les mapper, quelles valeurs calculer, quelles limites vérifier, et jusqu’à ses propres mises en page de formulaires, pour que les pages carburant et masses ressemblent à son formulaire papier.
• Un paquet ne contient aucun code exécutable. Des données et des déclarations, rien d’autre — l’installateur refuse scripts, binaires, archives imbriquées et liens symboliques. Un paquet tiers peut transformer votre plan de vol ; il ne peut jamais s’exécuter sur votre appareil.
• Les OFP PDF passent par le skill open source compagnon, prep-633, qui transforme un plan de vol imprimé en XML 633 validé.
• Les fichiers sont identifiés par leur contenu, pas par leur extension, et un fichier réellement ambigu vous demande simplement de quel format il s’agit.

Aucune infrastructure sol. Aucun projet d’intégration compagnie. Aucun déploiement côté dispatch. Si votre exploitant sait vous remettre un fichier de plan de vol, starLOG sait le voler — et s’il ne le sait pas encore, un paquet y pourvoit sans toucher à l’application.

La couleur dit d’où vient chaque valeur

C’est le détail que les pilotes remarquent en premier. Chaque valeur à l’écran est colorée selon son origine, et la convention ne fléchit jamais :

• Cyan — vous l’avez saisie
• Vert — l’app l’a calculée à partir d’autre chose sur le formulaire
• Magenta — le GPS, l’avion ou le flux de bord l’a renseignée automatiquement
• Jaune — l’autre appareil l’a poussée via la liaison pair à pair

Un coup d’œil sur une cellule et vous savez s’il faut lui faire confiance, la vérifier ou l’assumer. Sans badge, sans légende, sans avoir à toucher pour savoir.

Construit autour du déroulement réel du vol

• Les points se cochent seuls. Le moteur suit l’avancement le long de la route, et non la distance à un point — ainsi un décollage qui s’éloigne du routage avant de se mettre en route ne fait pas dévaler le pointeur dans le plan de vol. L’heure inscrite est celle du passage au plus près, interpolée : l’instant même qu’un FMS enregistrerait. En magenta, pour que vous voyiez que ce n’est pas vous.
• ETOPS et reclairance sont de premier rang. EEP, EXP et points équitemps sur la carte et dans le tableau, cercles de déroutement autour des terrains adéquats, dégagements en losanges ambre — et pour un vol à contingence réduite, le point de décision est résolu depuis le plan, le carburant requis y est calculé, et la marge poursuite ou déroutement s’affiche face à ce dont vous disposez réellement.
• Deux appareils, un seul log. Chargez le même plan de vol sur un iPhone et un iPad : ils s’appairent sur l’identité du vol sans aucune action, puis restent alignés, et un appareil qui rejoint tard est mis à jour sans jamais écraser des données plus fraîches.
• Un nouveau plan de vol en vol ne vous prend pas en traître. Importer une révision plus récente en vol l’archive et lève un badge ; l’adopter est un geste délibéré, jamais un remplacement silencieux sous vos doigts.
• Le compte rendu de vol fait partie du même dossier. Heures bloc, décollage, atterrissage, temps de nuit et équipage — plus le tech log : dégivrage, huile, avitaillements, répartition dans les réservoirs et rapprochement carburant — vivent à côté du log de navigation du même vol, alimentés par ce que vous avez déjà saisi plutôt que ressaisis.
• Préparation carburant et masses rapprochent le prévu du réel, chaque valeur dérivée étant calculée et colorée comme telle.

À vous de le réagencer

Chaque mise en page et chaque tableau de starLOG est décrit en XML, et au premier lancement ces modèles sont déposés dans un dossier que vous ouvrez dans l’app Fichiers sur l’iPad ou dans le Finder sur un Mac. Réordonnez les colonnes du log. Renommez une carte. Masquez une section dont vous ne vous servez pas. Changez la longueur des codes équipage pour coller au format de votre compagnie. Modifiez une formule. L’app reprend votre version — sans mise à jour, sans recompilation, sans ticket de support, sans développeur dans la boucle.

La plupart des logiciels de cockpit décident pour vous de ce qui compte. Celui-ci vous laisse le dire.

Conçu par un pilote, pour des pilotes

starLOG est développé par un commandant de bord Airbus en activité, dans le cockpit auquel il est destiné. Cela se voit à des choix qui ne survivraient jamais à une revue de spécifications.

Des surfaces presque noires plutôt que du noir pur, et un texte blanc cassé plutôt que du blanc pur, parce que le couple pur vibre sous l’éclairage de nuit du cockpit. Le cyan comme accent principal parce qu’il tient en plein soleil sur un parking, là où le rose et le violet lâchent. Tous les chiffres en chasse fixe et alignés à droite, parce qu’une colonne d’heures qu’on parcourt vaut mieux qu’une colonne qui fait joli. La densité d’information avant les blancs, parce qu’un pilote qui parcourt un log au FL390 veut plus de lignes visibles, pas plus de marges. Aucune animation sur les données critiques — ETA, carburant et statut ETOPS basculent d’un coup au lieu de s’installer en douceur. L’ambre pour « moins bien que prévu » et le rouge réservé au réellement critique, parce que les pilotes cessent de voir un rouge employé pour décorer. La répartition carburant disposée selon les six positions du formulaire papier, parce que c’est ce formulaire que vous recopiez.

Et le modèle de position multi-sources existe à cause d’un vol réel : sur une étape Bangkok–Paris, le brouillage GPS a fait disparaître entièrement la position certifiée de l’avion. Le récepteur multi-constellation d’un iPad l’a tenue à travers les vitres du cockpit, et le flux de position de la cabine l’a tenue tout du long. Ce n’est pas une idée sortie d’un atelier de feuille de route — pas plus que la réécriture du suivi au décollage, née de l’observation d’un pointeur qui dérive sur une vraie mise en piste.

À qui il s’adresse

Les grandes suites EFB se vendent aux compagnies sous forme de contrats flotte. Ce modèle ne peut structurellement pas servir le pilote qui veut son propre exemplaire. starLOG est fait pour :

• Les pilotes indépendants et sous contrat, qui changent d’exploitant et ne peuvent compter sur un déploiement compagnie
• Les petits exploitants — aviation d’affaires, fret, régional, ACMI, charter — sans budget d’intégration EFB
• Les pilotes de ligne qui veulent une sauvegarde personnelle de l’EFB compagnie, indépendante de celui-ci
• Les pilotes convoyeurs, instructeurs et d’aviation générale complexe, qui travaillent depuis un OFP sans système de flotte derrière eux

Ce que starLOG n’est pas

C’est un outil supplémentaire et personnel. Ce n’est pas une application EFB certifiée, pas un moyen de navigation primaire, pas un système de préparation des vols, et pas un carnet de route réglementaire au sens des exigences applicables aux exploitants — il tient un compte rendu de vol personnel. Il consomme des plans de vol ; il n’en produit jamais. Le commandant de bord confirme tout. Son utilisation en contexte opérationnel est soumise à la politique EFB de votre compagnie et à l’approbation réglementaire.

---

starLOG est en développement actif. Si vous volez avec un log de navigation papier à côté de vos cartes et préféreriez que non, contactez-nous au sujet de la bêta.