No-Code et Secteur Public : Comment OILHI a Hacké la Bureaucratie (Analyse 2026)

Soyons honnêtes : quand on pense "logiciel métier" dans l'administration française, on imagine des appels d'offres de 18 mois, des budgets à six chiffres et une ergonomie bloquée en 1998. Le projet OILHI (Outil d’Instruction pour Lutter contre l’Habitat Indigne), incubé chez beta.gouv, vient pulvériser ce cliché. En utilisant Glide, une solution No-Code souvent cantonnée aux petits projets, l'équipe a traité plus de 300 dossiers critiques d'habitat insalubre. Voici ce que les DSI ne vous diront pas : parfois, un outil imparfait sorti en 3 semaines vaut mieux qu'une usine à gaz livrée (ou pas) dans 3 ans. Décryptage d'un cas d'école.

La Stratégie du "Cheval de Troie" Technologique

Le No-Code n'est pas là pour remplacer la DSI, il est là pour la contourner quand l'urgence l'impose. Dans le contexte rigide du No-Code secteur public, cette agilité est souvent perçue comme une anomalie, alors qu'elle devrait être la norme pour les phases d'amorçage.

Le MVP "Commando" vs Le Cycle en V

Le problème classique de l'administration, c'est la paralysie par l'analyse. Pour lutter contre les marchands de sommeil, les mairies n'avaient pas besoin d'une architecture micro-services scalable à l'infini. Elles avaient besoin d'un outil maintenant. C'est là que l'approche d'Aurélien Migeot (Product Builder) est chirurgicale : utiliser Glide pour transformer un Google Sheet en application métier.

• Le constat brutal : En code propriétaire classique (Java/Angular), un tel outil aurait coûté entre 150 000 € et 200 000 € avec un délai de 9 à 12 mois de développement.

• La réalité OILHI : Un lancement en quelques semaines, un coût quasi-nul au démarrage (hors salaire), et une itération directe avec les agents de terrain.

On ne parle pas de "Spécifications Fonctionnelles Détaillées", on parle de livrer de la valeur immédiatement. Cette méthode permet de valider le besoin métier avant d'investir le moindre euro d'argent public dans un développement lourd. C'est l'essence même du Lean Startup appliqué à l'État.

La Rigueur Juridique par le Design

Le point fort inattendu de ce projet, c'est l'intégration de la complexité métier. L'habitat indigne, c'est une jungle de procédures : arrêtés de péril, diagnostics plomb, mises en demeure. L'outil ne se contente pas de stocker de la data. Il agit comme un tuteur pour l'agent municipal.

Si la loi change (et elle change tout le temps), l'application est mise à jour dans la journée. Essayez de faire ça avec un prestataire ESN classique : vous en avez pour trois mois de devis, de validation budgétaire et de recette. Ici, la veille juridique est directement injectée dans le produit via le back-office No-Code. C'est l'agilité ultime qui transforme un simple tableur en véritable assistant juridique de poche.

LIEN INTERNE : découvrez nos formations glide

Le Revers de la Médaille : Limites et Dette Technique

Tout n'est pas rose au pays du No-Code. Choisir la vitesse a un prix que vous devez connaître avant de vous lancer dans un projet No-Code secteur public. La dette technique n'est pas une fatalité, c'est un instrument financier qu'il faut savoir rembourser.

Analyse Comparative : Glide vs Développement Sur-Mesure

Voici un comparatif basé sur nos observations de projets similaires en 2026 :

Ce tableau montre clairement que Glide gagne sur la rapidité et le coût d'entrée, mais perd sur la souveraineté et la scalabilité à très grande échelle. C'est un arbitrage conscient.

Le Mur de la "Privacy" et du Coût

C'est le point que personne ne dit dans les conférences No-Code : Glide devient vite très cher quand on scale. Le modèle économique au "par utilisateur" est un tueur de budget pour le secteur public habitué aux licences globales ou au logiciel libre. De plus, on touche ici à de la donnée sensible (noms, adresses, état de salubrité, photos d'intérieurs privés).

Utiliser une solution américaine pose la question critique du RGPD et de la souveraineté des données. Pour un POC (Proof of Concept) ou un outil utilisé par une petite équipe "commando", le risque est calculé et acceptable. Mais si demain cet outil doit être déployé dans 36 000 communes, l'architecture devra changer radicalement.

Aurélien Migeot l'admet lui-même avec lucidité : "Quand on devra changer de technologie, on aura déjà un modèle testé". C'est la bonne philosophie : le No-Code sert à maquetter le futur, pas forcément à l'industrialiser éternellement. On accepte la dette technique pour acheter de la vitesse d'apprentissage.

L'Avenir : L'Hybridation ou la Mort

Il ne faut plus opposer les développeurs aux "No-Codeurs". C'est un débat stérile qui date de 2023. En 2026, la maturité technologique impose une collaboration étroite.

La DSI comme Architecte, le Métier comme Constructeur

L'exemple d'OILHI montre la voie. Les DSI doivent arrêter de voir le No-Code comme du "Shadow IT" dangereux, mais comme un laboratoire d'innovation à moindre coût. Le rôle de la DSI devient celui d'un urbaniste : elle définit les règles de sécurité, fournit les API, et laisse les experts métier (comme ceux qui gèrent l'habitat indigne) construire leurs interfaces.

Si l'application devient critique, la DSI reprend la main pour la "durcir" ou la recoder. C'est ce cycle vertueux qui manque cruellement aujourd'hui. On passe d'une logique de "Guichet" (je demande, j'attends) à une logique de "Plateforme" (je construis avec les briques sécurisées fournies).

Vers des Outils Métiers Jetables ?

On va être direct : peut-être que l'avenir, c'est l'outil jetable. Si une application coûte 500€/mois et fait gagner 200 heures aux agents, peu importe si elle n'est pas pérenne sur 10 ans. La tech évolue si vite qu'un outil développé aujourd'hui sera obsolète dans 3 ans de toute façon.

L'approche d'OILHI valide cette thèse : résolvons le problème d'aujourd'hui avec les outils d'aujourd'hui. On s'inquiétera de la migration quand le succès sera là. C'est une rupture totale avec la mentalité administrative du "bâtir pour l'éternité", qui aboutit souvent à bâtir des cathédrales vides. Accepter l'éphémère, c'est accepter l'efficacité immédiate.

FAQ Expert : No-Code et Administration

1. Glide est-il conforme RGPD pour une mairie ?

C'est une zone grise complexe. Les données sont souvent hébergées aux États-Unis par défaut. Pour des données non sensibles, c'est acceptable. Pour de l'état civil ou de la santé, c'est un "Non" ferme, sauf si vous utilisez Glide avec une source de données externe (BigQuery/SQL) hébergée en Europe (option Enterprise).

2. Quel est le coût réel d'une application comme OILHI ?

Au-delà de l'abonnement Glide (environ 100 à 250 €/mois pour une petite équipe), le coût principal est humain. Comptez un mi-temps "Product Builder" pour maintenir et faire évoluer l'outil. Le No-Code n'est pas du "No-Maintenance", c'est une erreur fréquente de sous-estimer ce poste.

3. Pourquoi ne pas avoir utilisé Bubble ?

Bubble aurait permis plus de flexibilité et un hébergement européen plus simple, mais la courbe d'apprentissage est de 3 mois minimum pour un niveau expert. Glide permet de livrer une version fonctionnelle en 3 jours. L'urgence du terrain et la simplicité de prise en main ont dicté le choix technique.

4. Peut-on connecter cet outil aux logiciels de la mairie ?

Oui, via des outils d'automatisation comme Make (ex-Integromat) ou Zapier. Cela permet de faire dialoguer Glide avec des bases de données existantes. Mais attention à ne pas créer des "usines à gaz" indébuggables sans documentation rigoureuse.

LIEN INTERNE : tutoriel make automatisation

5. Que se passe-t-il si Glide change ses tarifs ?

C'est le risque classique du "Vendor Lock-in". Si Glide double ses prix (ce qui est déjà arrivé par le passé), vous payez ou vous migrez. C'est pour cela qu'il faut toujours structurer ses données proprement (backend séparé) pour pouvoir changer d'interface si nécessaire sans perdre le cœur du système.

6. Est-ce que les agents municipaux acceptent facilement ces outils ?

Oui, car l'UX (Expérience Utilisateur) de Glide est supérieure à 99% des logiciels métiers administratifs vétustes. Quand l'outil est beau, fluide et mobile-first, l'adoption est quasi immédiate, ce qui réduit drastiquement les coûts de formation.

7. Quelle est la limite technique majeure rencontrée ?

La gestion des droits d'accès granulaires (Row Owners) est la principale friction. Définir "qui voit quoi" ligne par ligne est parfois laborieux sur Glide sans passer aux plans Business coûteux. Sur des organigrammes complexes, cela peut devenir un casse-tête.

8. Comment garantir la pérennité des données ?

En ne stockant jamais la "vérité" uniquement dans Glide. Utilisez une base externe (Airtable, Google Sheets, ou mieux Xano/Supabase) synchronisée. Si la société Glide ferme demain, vos données sont sauves et exploitables ailleurs.

OILHI n'est pas juste une "appli sympa". C'est la preuve qu'on peut digitaliser le service public sans attendre le "Grand Plan Numérique 2030". Mais attention : ne confondez pas vitesse et précipitation. Si vous touchez à de la donnée citoyen, assurez vos arrières juridiques ou préparez-vous à migrer vite. L'audace paie, mais la naïveté se paie cash.