Sentinel Health : comment j'ai gagne le Google Build with AI Buildathon Southern Africa 2026 avec une approche spec-driven

Le jeudi 30 avril 2026, de 17h00 a 19h00 SAST, j’ai participe au Google Build with AI Buildathon Southern Africa. C’etait un evenement virtuel organise par GDG et la Developer Ecosystem SSA Team. La contrainte etait volontairement nette : prendre un probleme pose, concevoir une solution, construire vite et montrer quelque chose qui fonctionne.

Mon projet, Sentinel Health, a termine premier.

Le resultat etait encourageant, mais la partie la plus utile etait le processus. Le buildathon est devenu un test compact de spec-driven development : passer d’une idee a une specification claire, transformer cette specification en petite PRD, puis construire a partir de cette PRD avec un backend, un frontend et un chemin de deploiement.

L’enseignement principal n’etait pas simplement que la programmation assistee par l’IA est rapide. Elle devient vraiment puissante lorsque les fondamentaux sont deja en place : un utilisateur clair, un workflow limite, une frontiere backend/frontend, un modele de securite et une cible de deploiement cloud.

La salle de presentation du Google Buildathon Southern Africa 2026.

Le brief et la specification

Le domaine etait la sante communautaire en contexte rural. L’utilisateur que j’avais en tete etait un agent de sante communautaire qui doit saisir les informations patient, reconnaitre les cas urgents et aider une equipe de district a voir ce qui se passe dans les cas entrants.

J’ai formule le prototype autour d’une question :

Peut-on accelerer l’admission pour un agent de sante communautaire tout en gardant les decisions critiques pour la securite deterministes et auditables ?

Cette formulation comptait beaucoup. Sans elle, le projet aurait pu deriver vers une demo dangereuse de type “diagnostic par IA”. Sentinel Health n’etait pas cela. La spec etait plus etroite : saisie, assistance au triage, signalement d’orientation et visibilite au niveau du district.

De la specification a la PRD, puis au build

Le premier bon reflexe n’etait pas le code. C’etait de transformer le brief en petite PRD.

Dans un build de 60 minutes, rediger une PRD peut sembler couteux. En pratique, cela fait gagner du temps parce que cela transforme une intention vague en decisions executables. Je m’en suis servi pour rendre explicites les points suivants :

• L’utilisateur est un agent de sante communautaire, pas un medecin.
• La saisie vocale peut aider a pre-remplir un formulaire, mais un humain doit verifier les champs structures.
• Les signaux de danger doivent etre detectes par des regles deterministes, pas par le jugement du modele.
• Le chemin IA est de l’aide a la decision, pas un diagnostic.
• La demo doit montrer une boucle complete : saisie, revue, signal d’orientation et tableau de bord de district.
• L’implementation doit avoir un backend et un frontend, pas seulement une demo de prompt.

Cette PRD est devenue le plan de construction. Le backend prenait en charge la saisie, les regles, les appels modele, la persistence et les contrats API. Le frontend prenait en charge la saisie vocale ou formulaire, la revue et le tableau de bord de district. Une fois cette separation claire, la programmation assistee par l’IA pouvait aider a generer et iterer sur le code sans renégocier en permanence la forme du produit.

Ce que Sentinel Health faisait

A la fin de l’heure, le prototype montrait un workflow complet des deux cotes du systeme :

• Un frontend React pour la saisie vocale et la saisie par formulaire.
• Un backend FastAPI pour la soumission des cas et les appels modele.
• Une extraction assistee par Gemini pour convertir du texte de saisie brouillon en champs structures pour la revue.
• Des regles deterministes de signaux de danger pour les orientations urgentes.
• Une assistance au triage via Gemini pour les cas non critiques.
• Une file d’attente de type offline pour simuler une connectivite instable.
• Un tableau de bord de district montrant le flux des cas, les orientations urgentes et les alertes de seuil.
• Un stockage d’evenements base sur BigQuery pour alimenter l’analyse.

La surface cloud etait volontairement pragmatique : Cloud Run pour le frontend et le backend, BigQuery pour les evenements, Secret Manager pour les secrets cote backend, Cloud Build et Artifact Registry pour le deploiement, et Cloud Logging pour la visibilite de base.

Containerise pour une demo vraiment deployee

Un detail comptait plus qu’il n’y parait : le backend et le frontend devaient tous les deux fonctionner dans des containers Docker. L’objectif n’etait pas seulement de montrer du code en local. L’objectif etait de mettre un POC deploye devant les juges pour qu’ils puissent ouvrir l’application, parcourir le workflow et interagir eux-memes avec la solution.

Cela voulait dire separer le systeme en deux services Cloud Run deployables independamment :

• Un container backend qui execute FastAPI.
• Un container frontend qui sert l’application React.

Cette separation gardait la demo honnête. Le frontend pouvait se concentrer sur la saisie, la revue et l’interaction avec le tableau de bord, tandis que le backend portait le contrat API, le workflow de triage, les appels modele, les regles et la persistence. Chaque cote pouvait ainsi etre construit, deployee et compris comme un service a part, au lieu de traiter tout le prototype comme une seule demo locale.

Sur le backend, j’ai utilise FastAPI avec des schemas Pydantic pour l’ingress et l’egress. Cela donnait a l’application un modele de donnees concret : les requetes entrant dans l’API devaient respecter un schema explicite, et les reponses sortant de l’API devaient etre structurees de facon previsible pour le frontend. Dans un projet avec du code genere ou assiste par l’IA, cette frontiere est importante. Elle donne au modele un contrat clair sur lequel construire, et au developpeur humain quelque chose de precis a verifier.

BigQuery etait un choix pragmatique pour le buildathon parce qu’il etait disponible, familier et pratiquement gratuit pour l’echelle du prototype. C’etait suffisant pour du stockage d’evenements et de l’analyse en aval dans une demo. Pour une vraie application de production, je ne traiterais pas BigQuery comme backend transactionnel principal. Les donnees d’admission patient, l’etat des cas, l’etat de revue, l’etat d’orientation et les mises a jour operationnelles relevent de l’OLTP. Une version de production aurait besoin de PostgreSQL ou d’une autre base transactionnelle derriere l’API, avec BigQuery reserve ensuite a l’analytique OLAP, aux rapports et aux vues de population.

L’architecture

L’architecture etait simple parce qu’elle devait l’etre :

Workflow d’architecture de Sentinel Health.

Le choix de conception le plus important etait de separer la securite basee sur des regles de l’assistance generative. Si un signal de danger est present, l’orientation ne doit pas attendre qu’un LLM “reflechisse” a la situation. Le modele peut aider a structurer des entrees brouillonnes et soutenir la revue, mais le plancher de securite doit etre banal, explicite et testable.

Ce que le buildathon a rendu evident

L’evenement a condense une lecon d’engineering familiere en deux heures : la plupart des prototypes echouent a cause d’un scope flou, pas a cause d’un outillage faible.

Avec des outils de developpement natifs pour l’IA, il est tentant de generer le code tout de suite. Cela marche pour le boilerplate, mais cela ne decide pas ce que le systeme a le droit d’etre. Le vrai travail humain reste dans le cadrage :

• Quelle est la plus petite histoire complete ?
• Quelle decision doit rester deterministe ?
• Quelle partie peut etre assistee par le modele ?
• Qu’est-ce qui appartient au backend ?
• Qu’est-ce qui appartient au frontend ?
• Qu’est-ce qui doit etre visible dans la demo pour que l’idee soit comprise ?

Pour Sentinel Health, la plus petite histoire complete n’etait pas “l’IA pour la sante”. C’etait la saisie, la revue, l’orientation urgente et la visibilite de district.

C’est la que les fondamentaux ont aide. Comme je maitrisais deja le cadrage produit, les frontieres API, le flux de donnees, le deploiement cloud et les contraintes de securite, les outils IA avaient quelque chose de concret a accelerer. La vitesse venait de la combinaison : specification claire d’abord, implementation assistee ensuite.

Prototype, pas produit

Il faut le dire clairement : Sentinel Health etait un prototype de buildathon, pas un logiciel clinique.

Il n’etait pas valide, pas pret pour la production et ne devait pas etre deploye dans un contexte de soins reel. Un vrai logiciel de sante exige une revue clinique, du travail reglementaire, des tests de securite, une evaluation en langues locales, une analyse de la vie privee, de la recherche utilisateur et des essais sur le terrain avec de vrais agents de sante.

La valeur du prototype etait plus etroite, mais utile : il montrait qu’un workflow complet pouvait etre esquisse rapidement, et il faisait ressortir les limites de conception qui compteraient si l’idee etait approfondie.

Apres l’evenement

J’ai ensuite documente Sentinel Health dans mon portfolio sur thamu.dev, et la mise a jour originale du portfolio a ete consignée dans la PR GitHub #56 : Buildathon SA 2026 (Sentinel Health, 1st), ouverte le 11 mai 2026.

Le depot du projet est ici :

github.com/ThamuMnyulwa/buildathon-60min-2026

La PR du portfolio est ici :

github.com/ThamuMnyulwa/thamu-dev/pull/56

Sentinel Health a termine premier au Google Buildathon Southern Africa 2026.

La lecon que j’en ai retenue

La principale lecon n’etait pas que l’IA rend tout facile. Ce n’est pas le cas.

La lecon etait qu’une boucle courte et spec-driven peut etre tres puissante : definir l’utilisateur, ecrire la spec, la transformer en PRD, separer le systeme en responsabilites backend et frontend, contraindre le modele de securite, construire le plus petit chemin end-to-end, le deploier quelque part de reel, puis laisser le prototype fonctionnel indiquer la prochaine question.

C’est une habitude utile bien au-dela des hackathons. Surtout dans les projets IA, ou les demos impressionnantes sont faciles et les systemes coherents beaucoup plus difficiles. La programmation assistee par l’IA peut faire passer une idee a un POC tres vite, mais la qualite de ce POC depend toujours des fondamentaux en dessous.