Comment ReadyAero est fait
ReadyAero n'est pas une liste de fonctions posées côte à côte. C'est un petit nombre de modules qui tournent autour d'une seule question, et qui se passent des choses très précises. Cette page montre lesquelles.
Une seule question
Tous les modules tournent autour de la même question : cet aéronef peut-il voler, légalement, maintenant ?
Aucun module n'y répond seul. Le module des consignes sait quelles consignes visent l'appareil — à partir du modèle, du numéro de série, de l'équipement installé. C'est le suivi d'entretien qui sait quand la prochaine échéance tombe, parce que lui seul a les compteurs. La réponse n'existe qu'au centre, là où ils se rencontrent.
↔ Le schéma défile de côté.
- Influence réciproque — il change l'état, l'état le contraint
- Influence à sens unique — il s'impose, rien ne le déplace
- Information seule — il rend compte, il ne décide rien
L'arc autour du noyau reprend le langage de couleur du produit : vert, ambre, rouge.
Les trois natures de lien
Les modules ne participent pas tous de la même façon. C'est la distinction qui compte le plus, et c'est celle qu'on oublie le plus vite quand on décrit un logiciel par sa liste de fonctionnalités.
Influence réciproque
Ils changent l'état, et l'état les contraint en retour.
Un vol validé fait avancer les compteurs de l'appareil — mais l'état refuse la fiche de vol si l'appareil est retiré du service. Une signature peut refermer une échéance — mais c'est l'état qui dit au technicien ce qui est dû, et qui l'avertit, par paliers, que sa licence approche de son expiration.
« Peut » n'est pas une précaution de langage. Une signature referme une échéance à deux conditions : que le technicien l'ait rattachée à son bon de travail — le produit ne devine jamais qu'un travail signé correspond à une tâche, quelqu'un le dit — et que le propriétaire ait accordé ce droit à cet atelier. Sans ce droit, l'échéance reste due et passe « en attente de confirmation du propriétaire », le dossier signé en référence. Le dossier et l’échéancier ne peuvent plus se contredire en silence : c’est le point.
Ces quatre-là sont les seuls qui changent l'état. Ce sont aussi les seuls dont une erreur de saisie déplace une échéance.
Influence à sens unique
Et c'est le seul. Une consigne s'impose à l'appareil, point. Rien de ce que le produit sait — l'usure, le retard, l'intention du propriétaire — ne la déplace d'un jour.
Ce n'est pas une figure de style, c'est écrit dans le logiciel : une tâche issue d'une consigne de navigabilité ne peut porter aucune tolérance, ni définie ni activée, alors que n'importe quelle autre tâche de suivi le peut. Le garde-fou est vérifié à chaque point d'entrée — création, modification, activation — et pas seulement caché dans l'interface.
Tout le reste du système est une conversation ; celui-ci est une contrainte.
Information seule
Ils rendent compte ; ils ne décident rien. Aucun des trois ne peut rendre un aéronef navigable ou non.
C'est une propriété, pas une faiblesse. Un tableau de bord qui pourrait modifier l'état serait un tableau de bord auquel on ne pourrait plus se fier pour le lire.
La boucle fermée
Retirez le noyau, et il reste une boucle : Suivi → Technicien → Équipement → Consignes → Suivi. Elle tourne sans entrée extérieure.
Le suivi dit ce qui est dû. Le technicien signe. Sa signature change une pièce. La pièce redéfinit quelles consignes visent l'appareil. Et ces consignes redeviennent des tâches de suivi.
Une erreur qui entre dans cette boucle y reste et se propage. Un numéro de pièce mal saisi ne s'arrête pas à la fiche : il change les consignes retenues, donc les tâches, donc les échéances, donc ce que le technicien voit au tour suivant.
C'est exactement ce qui rend la traçabilité utile. Elle n'empêche pas l'erreur — elle permet de la retrouver, et de savoir jusqu'où elle est allée.
↔ Le schéma défile de côté.
La boucle tourne sans entrée extérieure. Quatre portes l'alimentent, une seule sortie en part.
Quatre portes d'entrée
Une boucle fermée doit bien recevoir quelque chose du monde réel. ReadyAero en reçoit par exactement quatre portes — et une seule des quatre nous appartient.
1. Les vols
Les heures, saisies par le pilote sur sa feuille de vol, validées par le dispatch. C'est notre porte : c'est le seul des quatre flux que le produit organise de bout en bout. Seuls les vols validés comptent dans les compteurs de l'appareil.
2. Les consignes de navigabilité
Décidées par Transports Canada — et par la FAA et l'EASA pour ce qui relève d'eux. Personne ici n'en écrit le contenu, ni nous, ni vous.
Ce que vous décidez, c'est d'ouvrir la porte ou non. Chaque aéronef porte sa propre case « suivre les consignes de navigabilité », et elle part vide : un appareil que vous n'avez pas coché ne reçoit aucune consigne, et aucune visite n'est faite chez Transports Canada pour lui. Une consigne ne se télécharge que lorsqu'un aéronef réel en a besoin.
Et cet appareil-là le dit. Son écran de consignes annonce que le suivi n'est pas activé, au lieu d'afficher une liste vide — sans quoi « aucune consigne » et « rien n'est surveillé » se liraient pareil.
Une fois la porte ouverte, plus rien ne se négocie. Les consignes entrent, elles s'appliquent ou non, et la seule latitude porte sur la démonstration qu'elles ne s'appliquent pas — jamais sur une consigne qui s'applique.
3. Le programme d'entretien
Il n'est pas défini par un document, mais par l'ensemble de ceux que vous déclarez actifs : le formulaire d'approbation de calendrier d'entretien de Transports Canada (TC 24-0055A) et les chapitres d'entretien du constructeur. Vous téléversez vos PDF remplis, et ReadyAero en tire un modèle d'entretien.
Chaque document porte une case « Compte », qui répond à une seule question : ce document fait-il partie du programme d'entretien courant de cet aéronef ? L'interprétation se fait alors sur l'ensemble — une tâche n'est proposée au retrait que si aucun document actif ne la nomme.
C'est ce qui empêche le silence d'un document de valoir suppression. Un chapitre du constructeur ne parle que de son chapitre ; lu seul, son silence sur tout le reste se lisait comme « ce n'est plus au programme ». Sur un dossier réel, cette lecture avait produit 208 propositions de retrait portant sur des obligations de navigabilité.
Vous n'avez pas à ressaisir votre calendrier d'entretien. Vous donnez le formulaire que Transports Canada a déjà approuvé — celui que vous possédez déjà — et le suivi part de là.
Rien n'est enregistré tant que vous n'avez pas relu la proposition et cliqué « Créer le modèle ». La lecture est une proposition, jamais une décision.
4. Le carnet de bord, photographié
Vos carnets existent déjà, sur papier, signés. Vous les photographiez, et ReadyAero les lit — les entrées d'entretien, les révisions générales, les étiquettes de libération, et les pages de registre où un atelier a aligné des numéros de consigne avec leur date et sa signature.
C'est le registre légal qui parle, pas une saisie de plus. Une conformité lue au carnet peut fermer une consigne du suivi, et le motif consigné porte la date, le signataire et le texte de l'entrée — ce qu'un inspecteur lira dans six ans.
La lecture propose, elle ne décide jamais. Rien n'est coché d'avance, et fermer une consigne reste un geste que quelqu'un pose.
Une consigne récurrente n'est jamais fermée par cette porte. Elle se refait : le carnet dit quand elle a été exécutée la dernière fois, et cette lecture s'affiche à part, sans case à cocher. La fermer l'aurait sortie de votre suivi pour toujours.
Et le carnet ne fait pas que fermer : il contredit. Quand le suivi affirme une exécution qu'aucune page lue ne porte, ReadyAero le dit — une tâche qui paraît faite sans preuve au registre légal.
Ce qui sort
Les documents sortent de la boucle et n'y rentrent jamais : entrées de carnet, certifications après maintenance, exports scellés.
C'est ce qui les rend démontrables. Un document qu'un tour de boucle pourrait modifier n'attesterait plus rien. Un document scellé n'est donc jamais retouché : son empreinte est calculée sur les octets définitifs, le fichier n'est plus jamais réécrit, et une annulation ne change que la base — la copie déjà téléchargée par un client ne bouge pas, elle devient simplement vérifiable comme périmée.
L'agent n'est pas un neuvième module
Depuis la version 4.0, un agent est présent sur chaque page : on lui demande « ouvre un bon de travail pour C-GXXX », il pose les questions qui manquent, et il agit. Il n'a pourtant aucune place dans le schéma, et c'est voulu : il n'a aucun chemin à lui. Chaque geste qu'il pose passe par les mêmes portes que l'écran — le module payé, le droit de la personne connectée, l'accès à l'aéronef — et ce que l'écran refuse, l'agent le refuse aussi.
Il n'ajoute donc aucune nature de lien. C'est une autre façon de franchir les quatre portes d'entrée, avec les droits de la personne qui lui parle et pas davantage, et il demande sa confirmation avant tout geste irréversible.
L'abonnement est hors du cercle
Volontairement, et il faut le dire clairement : un client qui cesse de payer ne rend pas son aéronef non navigable. Il perd la lecture, pas l'état.
L'abonnement gouverne l'accès au logiciel. Il ne gouverne rien de l'aéronef. La navigabilité n'a jamais dépendu d'un logiciel, et ReadyAero est construit pour que ça reste vrai — c'est aussi pourquoi vous pouvez exporter vos données à tout moment, y compris après une résiliation.
ReadyAero est un outil d'aide au suivi. Il ne détermine pas la navigabilité d'un aéronef et ne remplace ni un technicien d'entretien d'aéronefs, ni le propriétaire, ni l'exploitant. La détermination de l'état de navigabilité et la certification après maintenance appartiennent à la personne habilitée qui signe.
Le détail se lit dans les conditions d'utilisation.
ReadyAero est conçu et exploité par FH Aeroservices, au Québec.
How ReadyAero is built
ReadyAero is not a list of features sitting side by side. It is a small number of modules turning around a single question, passing very specific things to one another. This page shows which ones.
A single question
Every module turns around the same question: can this aircraft fly, legally, right now?
No module answers it alone. The directive module knows which directives target the aircraft — from the model, the serial number, the equipment fitted. Maintenance tracking knows when the next deadline falls, because it alone holds the counters. The answer only exists at the centre, where they meet.
↔ The diagram scrolls sideways.
- Mutual influence — it changes the state, the state constrains it
- One-way influence — it imposes itself, nothing moves it
- Reporting only — it reports, it decides nothing
The arc around the core uses the product's own colour language: green, amber, red.
The three kinds of link
The modules do not all take part in the same way. That distinction matters more than anything else here, and it is the first thing lost when software is described as a list of features.
Mutual influence
They change the state, and the state constrains them back.
A validated flight advances the aircraft's counters — but the state refuses the flight sheet if the aircraft has been removed from service. A signature can close a deadline — but it is the state that tells the technician what is due, and that warns them, in steps, as their licence approaches expiry.
“Can” is not hedging. A signature closes a deadline on two conditions: that the technician linked it to their work order — the product never guesses that signed work matches a task, someone says so — and that the owner granted that right to this shop. Without it, the deadline stays due and moves to “awaiting owner confirmation”, with the sealed record referenced. The record and the schedule can no longer contradict each other in silence: that is the point.
These four are the only ones that change the state. They are also the only ones where a keying error moves a deadline.
One-way influence
And it is the only one. A directive imposes itself on the aircraft, full stop. Nothing the product knows — wear, delay, the owner's intention — moves it by a single day.
That is not a turn of phrase, it is written into the software: a task derived from an airworthiness directive can carry no tolerance at all, neither defined nor activated, where any other tracking task can. The guard is checked at every entry point — creation, editing, activation — not merely hidden in the interface.
Everything else in the system is a conversation; this one is a constraint.
Reporting only
They report; they decide nothing. None of the three can make an aircraft airworthy or not.
That is a property, not a weakness. A dashboard that could alter the state would be a dashboard you could no longer trust to read it.
The closed loop
Take the core away and a loop remains: Tracking → Technician → Equipment → Directives → Tracking. It turns with no outside input.
Tracking says what is due. The technician signs. That signature changes a part. The part redefines which directives target the aircraft. And those directives become tracking tasks again.
An error that enters this loop stays in it and spreads. A mistyped part number does not stop at the record: it changes which directives are retained, therefore the tasks, therefore the deadlines, therefore what the technician sees on the next turn.
That is precisely what makes traceability worth having. It does not prevent the error — it lets you find it, and see how far it travelled.
↔ The diagram scrolls sideways.
The loop turns with no outside input. Four doors feed it; a single output leaves it.
Four doors in
A closed loop still has to receive something from the real world. ReadyAero receives it through exactly four doors — and only one of the four is ours.
1. Flights
The hours, entered by the pilot on the flight sheet, validated by dispatch. This is our door: it is the only one of the four flows the product runs end to end. Only validated flights count towards the aircraft's counters.
2. Airworthiness directives
Decided by Transport Canada — and by the FAA and EASA for what falls to them. Nobody here writes their content, not us, not you.
What you decide is whether to open the door. Every aircraft carries its own "track airworthiness directives" checkbox, and it starts empty: an aircraft you have not ticked receives no directive at all, and no visit is made to Transport Canada on its behalf. A directive is downloaded only when a real aircraft needs it.
And that aircraft says so. Its directives screen states that tracking is off instead of showing an empty list — otherwise "no directives" and "nothing is being watched" would read the same.
Once the door is open, nothing is negotiable. Directives come in, they apply or they do not, and the only latitude lies in demonstrating that they do not — never over a directive that applies.
3. The maintenance programme
It is not defined by one document, but by the set of those you declare active: Transport Canada's maintenance schedule approval form (TC 24-0055A) and the manufacturer's maintenance chapters. You upload your completed PDFs, and ReadyAero derives a maintenance template from them.
Every document carries a "Counts" checkbox, which answers a single question: is this document part of the current maintenance programme for this aircraft? The reading is then done over the whole set — a task is proposed for removal only if no active document names it.
That is what stops a document's silence from meaning deletion. A manufacturer's chapter speaks only of its own chapter; read alone, its silence about everything else was read as "this is no longer in the programme". On a real file, that reading had produced 208 removal proposals bearing on airworthiness obligations.
You do not have to retype your maintenance schedule. You hand over the form Transport Canada has already approved — the one you already hold — and tracking starts from there.
Nothing is saved until you have reviewed the proposal and clicked "Create the template". The reading is a proposal, never a decision.
4. The logbook, photographed
Your logbooks already exist, on paper, signed. You photograph them and ReadyAero reads them — maintenance entries, overhauls, release tags, and the register pages where a shop has listed directive numbers with their date and signature.
This is the legal register speaking, not one more data entry. Compliance read from the logbook can close a directive in your tracking, and the recorded reason carries the date, the signatory and the text of the entry — what an inspector will read six years from now.
The reading proposes; it never decides. Nothing is pre-ticked, and closing a directive stays an act a person performs.
A recurring directive is never closed through this door. It is redone: the logbook says when it was last performed, and that reading appears on its own, with no checkbox. Closing it would have removed it from your tracking forever.
And the logbook does not only close things — it contradicts. When tracking claims a task was done and no page read carries it, ReadyAero says so: a task that looks done with no proof in the legal register.
What comes out
Documents leave the loop and never re-enter it: logbook entries, maintenance releases, sealed exports.
That is what makes them demonstrable. A document that a turn of the loop could alter would no longer attest to anything. So a sealed document is never touched again: its fingerprint is computed over the final bytes, the file is never rewritten, and cancelling one changes only the database — the copy a client already downloaded does not move, it simply becomes verifiable as superseded.
The agent is not a ninth module
Since version 4.0, an agent is present on every page: you ask it to “open a work order for C-GXXX”, it asks for whatever is missing, and it acts. Yet it has no place in the diagram, and that is deliberate: it has no path of its own. Every step it takes goes through the same doors as the screen — the paid module, the signed-in person's rights, access to the aircraft — and whatever the screen refuses, the agent refuses too.
So it adds no kind of link. It is another way through the four doors in, with the rights of the person talking to it and no more, and it asks for confirmation before any irreversible step.
The subscription sits outside the circle
Deliberately, and it deserves to be said plainly: a customer who stops paying does not make their aircraft unairworthy. They lose the reading, not the state.
The subscription governs access to the software. It governs nothing about the aircraft. Airworthiness never depended on a piece of software, and ReadyAero is built so that this stays true — which is also why you can export your data at any time, including after cancellation.
ReadyAero is a tracking aid. It does not determine the airworthiness of an aircraft and replaces neither an aircraft maintenance engineer, nor the owner, nor the operator. Determining airworthiness and signing the maintenance release belong to the certifying person.
The detail is set out in the terms of service.
ReadyAero is designed and operated by FH Aeroservices, in Quebec.