Un outil construit sur une feuille de calcul, utilisé par des agents municipaux, qui a contribué à sortir une centaine de familles d’un logement dangereux.
Ce n’est pas une démonstration de produit. C’est un service public en fonctionnement.
Aurélien Migeot l’a construit sur Glide. Son parcours, et surtout la manière dont il a cadré les limites de son outil, disent quelque chose d’utile bien au-delà du secteur public.
De Too Good To Go à beta.gouv : quel parcours ?
Aurélien Migeot n’est pas informaticien de formation.
Il débute sa carrière dans le marketing chez Too Good To Go, où il explore les outils d’automatisation et de growth. C’est là qu’il découvre Glide, qui transforme un simple Google Sheet en application.
Le déclic est immédiat : enfin un moyen de concrétiser ses idées sans passer par des mois d’apprentissage en développement.
D’abord pour des projets personnels, puis en freelance. Une première mission pour créer un MVP dans le cadre de beta.gouv devient un projet de long terme : l’outil existe encore deux ans et demi plus tard.
C’est le premier enseignement du parcours, et il est contre-intuitif. Un prototype construit vite n’est pas condamné à être jetable. Il l’est quand personne ne s’en sert. Celui-ci a survécu parce qu’il répondait à un problème que ses utilisateurs avaient tous les jours.
OILHI : à quoi sert l’outil ?
OILHI — Outil d’Instruction pour Lutter contre l’Habitat Indigne — est né au sein de beta.gouv. Sa mission : accompagner les collectivités locales dans le traitement des logements indignes, ceux qui mettent en danger leurs occupants.
Toiture percée, humidité, murs fissurés, nuisibles : chaque situation implique une procédure administrative spécifique, souvent complexe, avec ses délais, ses pièces et ses actes.
L’application s’adresse aux agents municipaux. Des gens parfois peu formés à ces procédures, souvent isolés face à des dossiers lourds, et qui n’ont ni le temps ni les moyens de devenir juristes du logement.
OILHI les guide pas à pas : diagnostic de la situation, génération automatique de modèles d’arrêtés, rappels aux échéances, suivi du dossier dans le temps. Un assistant numérique, discret mais efficace.
L’outil a traité plus de 300 situations, dont une centaine résolues.
Pourquoi Glide, et pas autre chose ?
Le choix est pragmatique, et assumé.
Glide permet de lancer vite, d’itérer souvent, sans équipe technique dédiée. Les cycles de développement sont courts, ce qui a une conséquence directe sur la qualité du produit : un retour d’un agent municipal le lundi peut être intégré dans la semaine.
Sur un sujet où personne ne sait à l’avance ce dont les utilisateurs ont besoin — et où les utilisateurs eux-mêmes ne savent pas toujours le formuler —, cette boucle courte vaut plus que n’importe quelle spécification écrite en amont.
C’est le raisonnement qu’on applique aussi dans une PME quand on construit un outil métier : la vitesse n’est pas là pour livrer plus tôt, elle est là pour se tromper moins longtemps.
Comment tenir la veille juridique dans un outil ?
C’est la partie du projet la plus intéressante, et la moins technique.
Les textes évoluent. Une réforme, un arrêté, une modification légale, et une procédure change. Un outil qui produirait des documents périmés serait pire qu’inutile : il exposerait les collectivités qui lui font confiance.
La réponse d’OILHI n’est pas une automatisation. L’outil est mis à jour, les modèles de documents changent, l’arbre décisionnel s’ajuste — parce qu’une équipe le fait. Des expertes métier intégrées au projet, en lien avec les préfectures, suivent l’évolution des textes et répercutent.
Cette veille donne aux collectivités une sécurité juridique précieuse, notamment face aux marchands de sommeil, qui maîtrisent parfaitement les failles des procédures.
Retenez le mécanisme, il se transpose partout. Dans tout domaine réglementé — facturation électronique, RGPD, obligations sociales —, ce qui tient la conformité d’un outil n’est pas la plateforme sur laquelle il est construit. C’est la personne dont c’est le travail de la maintenir à jour.
Des limites connues, et cadrées
Aurélien connaît les limites du no-code : coût par utilisateur, dépendance à la plateforme, absence de propriété du code, questions de sécurité, montée en charge sous certaines conditions.
Plutôt que de les nier, il les anticipe. Les données sensibles sont évitées ou cloisonnées. Les documents légaux sont maintenus en continu par les expertes métier de l’équipe.
Et sur la dépendance à l’outil, sa position est nette :
« Quand on devra changer de technologie, on aura déjà un modèle testé, utilisé et validé. Ce sera beaucoup plus simple de le recoder. »
C’est la manière la plus utile de traiter le sujet du verrouillage fournisseur. L’application n’est pas le patrimoine : le patrimoine, c’est le modèle de données, l’arbre décisionnel et les procédures validées par l’usage. Ça, ça se réécrit sur n’importe quelle technologie.
Glide ne fait pas tout, par ailleurs. Pas de gestion fine des erreurs, impossibilité de publier sur les stores, facturation par utilisateur qui devient lourde quand le nombre d’utilisateurs monte. Ces limites ferment certains projets, et il faut les regarder avant de commencer, pas après.
Le métier derrière l’outil
Aurélien Migeot n’a pas de formation d’informaticien, et c’est le point le plus intéressant de son parcours.
Il vient du marketing. Ce qu’il apporte à OILHI n’est pas une compétence technique rare : c’est la capacité à comprendre un métier qu’il ne connaissait pas, à traduire des procédures administratives en arbre de décision, et à corriger vite quand un agent lui dit que ça ne marche pas comme prévu.
C’est la définition du travail de product builder, un rôle qui se répand dans les PME sous des noms variés — responsable des outils, ops, chargé de transformation. Le profil type ne sort pas d’une école d’ingénieurs. Il sort du métier, et il a appris à outiller.
Cette bascule change la manière dont une PME peut aborder ses propres chantiers. La question n’est plus « avons-nous un développeur », mais « avons-nous quelqu’un qui connaît assez bien le process pour décider ce que l’outil doit faire ». C’est une compétence beaucoup plus courante en interne qu’on ne le croit, et beaucoup plus rare à recruter à l’extérieur.
Ce que ce projet apprend à une PME
Le contexte est public, les enseignements ne le sont pas.
Un outil sert d’abord ceux qui n’ont pas demandé d’outil. Les agents municipaux d’OILHI n’ont pas rédigé de cahier des charges. Ils avaient des dossiers lourds et pas de méthode. C’est exactement la situation d’un responsable d’opérations ou d’un DAF face à un process qui tient sur une personne : le besoin existe, il n’est simplement formulé nulle part. Aller le chercher sur le terrain vaut mieux qu’attendre qu’on vous l’écrive.
La procédure vaut plus que l’interface. Ce qui fait la valeur d’OILHI, c’est l’arbre décisionnel : quelle situation appelle quelle démarche, dans quel ordre, avec quelles pièces. L’application n’est que la façon de le rendre utilisable. Dans une PME, c’est la même chose — la valeur d’un outil métier tient au modèle de données et aux règles qu’il encode, pas aux écrans.
Le patrimoine, c’est le modèle validé. La position d’Aurélien sur le changement de technologie se transpose directement. Si vous construisez sur une plateforme dont vous ne possédez pas le code, gardez au moins la maîtrise de ce qui compte : la structure de vos données, vos règles de gestion, vos documents types. Ça se réécrit ailleurs. Une interface, non — et ce n’est pas grave.
Quelqu’un doit tenir la conformité. La veille juridique d’OILHI est humaine, pas automatique. Toute PME qui outille un process réglementé — facturation électronique, traitement de données personnelles, obligations sociales — doit désigner cette personne. Sans elle, l’outil produit des documents périmés avec l’assurance d’un logiciel.
Ces quatre points n’ont rien à voir avec le no-code. Ils décrivent ce qui sépare un outil utilisé d’un outil abandonné, quelle que soit la technologie qui le porte.
Ce que ce projet dit du choix d’un outil
Pour Aurélien, ces limites ne sont pas une raison d’écarter le no-code. Il suffit de choisir le bon outil pour le bon usage.
« C’est facile d’être déçu du no-code. Mais parfois, ce n’est pas le no-code le problème. C’est qu’il ne fallait juste pas l’utiliser. »
La phrase mérite d’être lue deux fois, parce qu’elle vaut pour n’importe quelle technologie. L’échec attribué à un outil est presque toujours un échec de cadrage : on a choisi avant d’avoir compris le besoin.
Pour la suite, sa position est claire : pas de guerre de chapelles entre no-code, low-code, IA et développement classique. Chaque projet choisit sa base technologique, quitte à mélanger les approches. Le no-code ne remplacera jamais tout. Mais bien utilisé, il change beaucoup.
Trois questions à se poser avant de démarrer, que ce projet illustre bien. Vos utilisateurs auront-ils l’outil sous les yeux assez vite pour le corriger ? Les données sensibles peuvent-elles rester hors de la plateforme ? Et si vous deviez changer de technologie dans deux ans, que garderiez-vous ?
Si vous avez trois réponses, vous avez votre outil.
OILHI, construit sur Glide par un ancien marketeur, a instruit plus de 300 situations d'habitat indigne dont une centaine résolues, et tournait toujours deux ans et demi après. Ce que le projet montre : la valeur tient au modèle de données et aux procédures validées, pas à la plateforme — et c'est cela qu'on emporte le jour où l'on change de technologie.
Questions fréquentes
Qu'est-ce qu'OILHI ?
L'Outil d'Instruction pour Lutter contre l'Habitat Indigne, né au sein de beta.gouv. Il accompagne les collectivités locales dans le traitement des logements qui mettent en danger leurs occupants : diagnostic, génération de modèles d'arrêtés, rappels, suivi de dossier.
Sur quel outil OILHI est-il construit ?
Entièrement sur Glide, qui transforme une feuille de calcul en application. Un choix assumé : cycles de développement courts, retours utilisateurs intégrés vite, aucune équipe technique dédiée à mobiliser.
Quels résultats l'outil a-t-il produits ?
Plus de 300 situations traitées, dont une centaine résolues. L'outil, né d'une mission de MVP, était toujours en service deux ans et demi plus tard.
Comment un outil no-code suit-il l'évolution de la loi ?
Par une équipe, pas par une automatisation. Chez OILHI, des expertes métier en lien avec les préfectures mettent à jour les modèles de documents et l'arbre décisionnel à chaque réforme. C'est ce travail humain qui donne la sécurité juridique, pas la plateforme.
Quelles limites de Glide ce projet a-t-il rencontrées ?
Pas de gestion fine des erreurs, impossibilité de publier sur les stores, facturation par utilisateur qui devient lourde à l'échelle, et dépendance à la plateforme puisqu'on ne possède pas le code. Ces limites ont été cadrées plutôt que niées.
