Notre mission
RescueLog est né d’un poste de secours, pas d’un tableur de marché. Cette page explique ce que nous cherchons à changer, comment nous construisons, et où nous en sommes réellement.
Le constat
Un dispositif prévisionnel de secours mobilise des dizaines de bénévoles, couvre des milliers de personnes et engage la responsabilité d’une association agréée. Il se pilote pourtant, presque partout, avec un plan imprimé, un tableau blanc, une radio et des fiches papier.
Ce n’est pas un défaut de volonté. C’est l’absence d’un outil écrit pour cette réalité : bénévole, mobile, sous la pluie, sans réseau garanti, avec des données de santé à protéger et une obligation de traçabilité à tenir.
Chaque minute passée à recopier une fiche est une minute qui n’est pas passée auprès d’une victime.
« J’ai trop souvent vu mes collègues lutter avec des fiches papier sous la pluie, perdre du temps à retranscrire des informations vitales, ou simplement manquer d’outils adaptés à la réalité de nos interventions. »
Nos partis pris
Elles ne se voient pas à l’écran. Elles décident pourtant de ce qui arrive le jour où quelque chose tourne mal.
Une interface qui masque un bouton ne protège rien. Les droits sont écrits dans PostgreSQL, sur chaque table, et c’est la base qui refuse.
Une erreur d’affichage ne devient jamais une fuite de dossier médical.
Les statuts d’équipe, les alertes et les décisions s’ajoutent au journal ; ils ne remplacent pas la ligne précédente.
Le déroulé du dispositif reste lisible après coup, pour le retour d’expérience comme pour l’enquête.
Le dossier ouvert par le poste de commandement est celui que l’équipe remplit, celui qui alimente les statistiques et celui qui s’exporte.
Pas de recopie le lendemain, donc pas d’écart entre ce qui s’est passé et ce qui est archivé.
Une alerte de détresse part avant d’avoir sa position, parce qu’une alerte qui attend un fix GPS est une alerte perdue.
Les cas dégradés sont traités dans la conception, pas laissés à la chance.
Un secouriste qui découvre une limite en intervention ne nous fera plus confiance. Nous préférons l’écrire avant.
Notre feuille de route publique distingue ce qui tourne de ce qui est encore au tableau.
Transparence
Un logiciel qui manipule des données de santé se juge sur ce qu’il tient, pas sur ce qu’il promet. Voici l’état, sans arrondi.
Le contenu des bilans est chiffré en AES-256-GCM, lié à son intervention : un bilan déplacé d’un dossier à l’autre ne se déchiffre pas.
Chaque table porte ses politiques de sécurité au niveau ligne. L’appartenance à l’organisation et à l’événement décide de ce qui est lisible.
Les quatre parties du chapitre 4 sont couvertes — page de garde, consignes, renseignements, synthèse — dans un registre chiffré que la base refuse de modifier ou d’effacer après saisie, jusqu’au rapport PDF de fin de mission.
Héberger des données de santé pour le compte d’associations impose la certification HDS et une AIPD. Le cadrage est écrit ; ni l’une ni l’autre ne sont acquises à ce jour.
Tant que la certification HDS n’est pas obtenue, nous le disons ici plutôt que de le laisser découvrir dans un appel d’offres.
Feuille de route
Trois colonnes plutôt qu’une promesse. Le détail de l’existant se lit sur la page fonctionnalités.
Ce qui tourne aujourd’hui et sert sur des dispositifs réels.
Engagés, avec un cadrage écrit et des décisions déjà tranchées.
Identifié, chiffré, mais pas encore engagé — et dit comme tel.
Nous cherchons des associations prêtes à éprouver RescueLog sur un dispositif réel et à nous dire ce qui ne va pas. Les retours de poste pèsent plus lourd, chez nous, qu’une étude de marché.
Libérer l’action, sauver plus de vies.