Comment nous construisons CareLogic

La porte : rien ne part sans le vert

Rien n'est mis en production tant que la porte n'a pas apposé son visa sur le commit. Cette porte est autohébergée et conteneurisée, sans aucune dépendance de facturation externe, parce que le chemin critique d'un produit de qualité n'a pas à dépendre de la disponibilité d'un service SaaS tiers. Le script de déploiement refuse de provisionner tant que le visa de la porte ne correspond pas au commit en cours. Impossible pour un regroupement de commits (squash) de glisser au travers un commit qui n'a pas franchi la porte.

Chaque étape existe pour rendre la discipline exécutoire, et non simplement respectée jusqu'au jour où elle glisse.

Ce que la porte complète exécute, dans l'ordre :

1. Audit des vulnérabilités des dépendances. Un analyseur de paquets confronte les paquets installés au registre d'avis de sécurité PyPI/OSV. Les avis sans correctif connu peuvent être acceptés de façon explicite et consignés; tout le reste bloque net.

2. Chaîne de migration complète sur un vrai Postgres. L'outil de migration rejoue tout l'historique des migrations sur un vrai conteneur Postgres tout neuf, sous un rôle propriétaire sans droits de superutilisateur, calqué sur la production. On y met à l'épreuve les instructions de révocation de permissions et les déclencheurs en ajout seul que le raccourci de création automatique du schéma laisse de côté, autant de bogues qu'une base de test SQLite masque complètement.

3. Suite de tests complète sur Postgres. Toute la batterie de tests unitaires et d'intégration tourne sur l'instance Postgres conteneurisée, jamais sur SQLite. On attrape ainsi les écarts de dialecte de base de données qui, autrement, se rendraient en production sans bruit.

4. Contrôle des contraintes Postgres. Une vérification dédiée confirme que les contraintes de sécurité de la base et les protections de la piste d'audit sont réellement en vigueur après la migration, plutôt que tenues pour acquises.

5. Sonde HTTP en direct. On sonde le conteneur applicatif en marche : le point de santé doit répondre 200; la documentation de l'API doit être désactivée; une requête non authentifiée vers une route d'administration doit se buter à un 401.

6. Vérification du rendu (vrai PDF). On construit une image capable de faire le rendu, puis on s'en sert pour produire un exemplaire de chaque type de rapport, Rapport final, Pulse et Synthèse de direction, sous forme de vrai fichier PDF. La porte impose le bon chemin de rendu (Paged.js) et écarte le chemin Chromium, qui escamote les en-têtes de bas de page et laisse des blancs. La chaîne d'outils est la même qu'en production.

7. Suite de bout en bout en navigateur. Les parcours en navigateur (Playwright) s'exécutent contre un serveur en direct que la suite de tests démarre elle-même. Le moindre échec d'assertion fait tomber la porte dès la première occurrence.

8. Apposition du visa de déploiement. Quand la porte complète passe au vert, elle inscrit un visa. Le script de déploiement vérifie ce visa avant de provisionner. C'est le visa qui fait autorité, pas un simple indicateur.

Le socle de sécurité toujours actif.

La porte fait la part des choses entre un changement Python bien circonscrit et un changement à risque. Pour un changement circonscrit, elle ne rejoue qu'un sous-ensemble de la suite, choisi par la sélection par impact. Peu importe l'ampleur, cinq vérifications tournent toujours et ne peuvent jamais être contournées par la sélection par impact :

Un changement de feuille de style ou de gabarit déclenche en plus la couche visuelle : conformité des composants et du visuel (contrôle structurel des classes du système de composants) et la suite de bout en bout. Quand le changement touche une ressource dont dépend réellement le rendu des rapports PDF, un jeton de conception partagé, une police ou un gabarit de rapport, il déclenche aussi la vérification du rendu, car seul le rendu d'un vrai PDF détecte une régression de mise en page.

La porte fondée sur l'impact des changements.

La sélection par impact (mise à profit entre deux exécutions complètes pour itérer vite sans risque) tranche d'elle-même si un changement se prête à la sélection par impact ou s'il doit passer à la suite complète. Un changement touchant les fichiers du cœur de la couche de données passe à la suite complète sans condition. Un changement aux routes web ou API ajoute toujours la suite de bout en bout. Un changement de gabarit ou de feuille de style ajoute la conformité visuelle, et n'ajoute la vérification du rendu PDF que s'il touche une ressource à partir de laquelle les rapports sont rendus. Un changement hors périmètre (migrations, dépendances, configuration) passe automatiquement à la porte complète.

Ce qu'une journée de revue adversariale a ajouté.

En juillet 2026, nous avons braqué six angles de revue indépendants sur le produit en service, comme nous le ferions pour un client, et livré chaque correctif le jour même. Trois des retombées en disent plus long sur le système que les constats eux-mêmes :

• L'outillage de déploiement a refusé une configuration de serveur Web défectueuse le jour même d'un déploiement en production. Les visiteurs n'ont rien vu; en soirée, le refus était devenu un volet permanent de la porte.
• La restauration se répète, elle ne se présume pas : chaque nuit, une copie chiffrée de la base de production se restaure dans un conteneur propre et les comptes de lignes sont vérifiés contre la source. Une sauvegarde jamais restaurée n'est qu'une hypothèse.
• Chaque test a désormais une voie qui l'exécute. Un recensement a mis au jour des suites qu'aucun pipeline ne lançait; elles ont rejoint une voie ou échoué bruyamment. Un test que personne n'exécute émet de la confiance et ne protège rien.

L'examinateur mérite sa propre note. Nous avons braqué sur le code le même outillage d'IA qui participe à la construction de CareLogic (Claude Code sur Fable 5 d'Anthropic, le modèle le plus performant pour ce type de travail au moment de la revue), avec pour mandat de le remettre en question de façon adversariale et de faire remonter tout ce qui cloche. Il a relevé de vrais défauts aux jointures, corrigés et livrés le jour même, et il a jugé le cœur sain : dépendances réelles, aucun secret dans le code, socle de confidentialité solide, moteur de notation exact. Une revue qui ne trouve rien n'apprend rien. Celle qui trouve de vraies jointures et juge malgré tout le cœur solide a mérité son verdict.

L'autoévaluation : composite 91/100, publiée avec les jaunes

Nous passons CareLogic à son propre diagnostic, au fil du moteur de notation en production, en répondant honnêtement. Le résultat est publié ici, daté et rattaché à sa version, y compris les éléments qui ne sont pas au vert.

Résultat actuel (moteur actuel, juin 2026; évalué le 2026-06-07; score recalculé au moteur actuel avant publication) :

C'est dans la progression que réside l'honnêteté.

La toute première fois, CareLogic a récolté 48/100, avec trois critiques. C'était le fidèle reflet d'un instrument nourri de renseignements incomplets : il ne peut pas deviner ce qu'on ne lui a pas dit. Une fois qu'une personne chevronnée a apporté le contexte qui change la lecture honnête (la responsabilité de la qualité est répartie au fil d'un modèle de gouvernance documenté, d'un processus de revue à plusieurs relecteurs et de notre journal de décisions, au lieu de reposer sur une seule personne; l'outillage de développement s'exécute avant le lancement sur des données sauvegardées, jamais sur les données réelles de clients; une personne consultante relit chaque rapport généré, mot pour mot, avant sa remise), la lecture corrigée s'établissait à 77/100, sans aucune critique. Il ne s'agissait pas de revoir notre jugement sur l'organisation; l'instrument avait enfin en main ce qu'il lui fallait.

Par la suite, le score n'a bougé qu'au rythme du vrai travail accompli :

• Rédiger notre politique d'utilisation de l'IA et notre spécification de gouvernance de l'IA n'a rien changé au pilier Processus. Une intention couchée sur papier n'est pas un contrôle en fonction.
• Le harnais d'évaluation a fait grimper Processus, mais l'a délibérément laissé un point sous la ligne verte, parce qu'un harnais ne peut pas se donner à lui-même son ensemble de référence.
• Processus n'a franchi le vert qu'une fois qu'une personne consultante a relu et approuvé un mandat réel comme exemple de référence, ce que seul un humain peut faire.

Chaque jaune que nous affichons sur nous-mêmes renvoie à un service qu'offre SQALogic : évaluation systématique et tests de régression de l'IA, formalisation de la gouvernance de l'IA, continuité et résilience du savoir. Ces lacunes, nous les avons trouvées en jouant honnêtement le jeu de notre propre diagnostic.

La trouvaille récursive.

La meilleure carte de visite d'un outil de qualité, c'est de débusquer ses propres défauts avant tout le monde.

Passer le diagnostic à son propre instrument, puis en éplucher les réponses, a fait ressortir un vrai défaut de configuration avant le lancement : la critique de biais d'IA (« des fonctionnalités d'IA sont mises en production sans test de biais ») était branchée sur la question de latence au lieu de la question de biais. Un goulot de latence aurait déclenché en douce une alerte urgente de biais d'IA; une organisation qui ne teste vraiment pas ses biais, elle, n'aurait rien déclenché du tout. L'autoaudit l'a rattrapé et nous avons corrigé le tir avant le lancement. La vérification des associations a confirmé que tous les autres branchements étaient justes.

Gouvernance de l'IA

CareLogic recourt à l'IA à deux endroits. La frontière qui les sépare est de nature structurelle, ce n'est pas une simple consigne.

Le moteur de notation du diagnostic est déterministe. Les scores sortent d'un moteur purement fonctionnel confronté à des critères arrêtés d'avance. La note remise au client ne peut ni halluciner, ni dériver d'une exécution à l'autre, ni changer au gré de la version d'un modèle. C'est l'unique issue possible, vu la manière dont le moteur est écrit. Jamais un modèle de langage n'entre en jeu dans la notation.

La synthèse, elle, est générative, bornée et relue par un humain. La transcription de l'entretien individuel et la production du rapport final s'appuient sur un modèle de langage qui tourne en local, sur la machine de la personne consultante. Aucune clé d'API de modèle d'IA ne se trouve sur le serveur de production : il lui est donc physiquement impossible d'appeler un modèle externe. Générer côté serveur est hors de portée. C'est un mécanisme qui contraint, pas un vœu de politique.

La couche de génération est tenue en bride par plusieurs contrôles :

• Vérification par traçabilité. Toute citation d'un rapport généré doit se retrouver dans la transcription d'origine par appariement mot pour mot normalisé (insensible à la casse et aux espaces); une attribution que le modèle n'arrive pas à ancrer fait tomber une porte avant même l'assemblage du rapport. La relecture par la personne consultante sert de filet pour toute reformulation qui n'est pas au mot près.
• Portes de complétude. L'assemblage du rapport s'assure que toutes les sections attendues sont là et que la matière source essentielle s'y retrouve.
• Porte humaine. La personne consultante relit chaque rapport final au complet avant sa remise. C'est une étape de processus obligatoire, consignée dans notre politique d'utilisation de l'IA, dont le dossier d'attestation garde la trace.
• Provenance par rapport. Chaque rapport final note l'identifiant du modèle et la version d'invite ayant servi à le produire. La version d'invite est horodatée et figée côté serveur; un changement de version de modèle passé sous silence pourrait échapper à la vigilance sans l'attestation de la personne consultante, d'où son caractère obligatoire. La personne consultante conserve la transcription d'origine nécessaire à une reproduction intégrale.
• Résidence des données. La transcription de l'entretien individuel ne touche jamais le serveur. Pour les mandats qui exigent une résidence canadienne des données, la personne consultante fait la génération chez un fournisseur retenu par le client; le dossier d'attestation note le fournisseur, le modèle et la région. La mise en place des adaptateurs se fait au cas par cas, mandat par mandat. CareLogic n'enferme pas les mandats chez un seul fournisseur.
• Examen des fournisseurs. Avant de retenir un fournisseur ou un modèle pour la génération destinée aux clients, on confirme les conditions de résidence et de conservation des données et on consigne la décision. L'examen recommence à chaque changement de fournisseur ou de version de modèle.

Notre politique d'utilisation de l'IA et notre spécification de gouvernance de l'IA avaient été versés au dépôt avant même la rédaction de cette page. Les contrôles qu'ils décrivent étaient en vigueur avant que les documents ne leur donnent un nom.

Moteur actuel, juin 2026 · Évalué le 2026-06-07 · Score recalculé au moteur actuel avant publication.