Housing AI - Agregateur de logements

LocaSur, publié aussi sous le nom Housing AI sur housing-ai.ca, est une plateforme de location immobilière au Québec que j'ai construite seul. Son idée centrale : des références vérifiées dans les deux sens, locataire et propriétaire. Le système fonctionne techniquement. Je l'ai gelé avant de le mettre en marché, et c'est cette décision que je raconte ici.

Le contexte : qui, pourquoi, quelle contrainte

Projet perso, pas un mandat client. L'idée de départ tenait en une phrase : rassembler les logements disponibles au même endroit et régler le vrai problème de la location, la confiance entre un propriétaire et un candidat qu'il ne connaît pas.

Trois contraintes que j'ai portées du début à la fin. Je suis seul, sans audience et sans budget d'acquisition. Ensuite, une place de marché a besoin de liquidité des deux côtés en même temps, et mon audit growth a pointé l'écart : le modèle que je construisais demandait plus de volume d'annonces simultanées que le terrain visé n'en offrait. Ce n'est pas un jugement sur le terrain, c'est un problème de mécanique de place de marché, et il se pose avant d'écrire la première ligne. Enfin, le projet a vécu sous deux noms en parallèle dès le départ, Housing AI pour le domaine et LocaSur pour la marque, ce que l'audit a listé comme identité de marque fragmentée.

Le problème : ce qui coinçait vraiment

L'article 1904 du Code civil du Québec est d'ordre public : un propriétaire ne peut exiger aucune somme autre que le loyer, et la jurisprudence a déjà ordonné le remboursement de frais d'enquête de crédit réclamés à un locataire. La Commission d'accès à l'information interdit en plus de collecter le NAS, les coordonnées bancaires, le salaire, les relevés de paie ou le nom de l'employeur, et interdit de conserver une copie de la pièce d'identité. Le modèle américain, où le proprio fait payer la vérification au candidat, est risqué voire interdit ici. J'allais copier ce playbook. Il m'aurait exposé à une pratique illégale, et il aurait exposé les utilisateurs avec moi.

Sur la technique, l'agrégation d'annonces résistait, pour deux raisons de nature différente. Certaines sources rendent leur contenu côté client de façon si instable qu'un script headless casse au premier changement de gabarit, et le maintenir devient un travail à temps plein. D'autres refusent explicitement l'accès automatisé, et ce refus tranche la question : je ne récupère pas de données chez un exploitant qui l'interdit, quelle que soit la facilité technique de le faire. Cette ligne-là n'est pas négociable sur un mandat non plus, parce que le risque juridique atterrit chez le client autant que chez le prestataire.

Le parser de requêtes en langage naturel, lui, importait transformers et faisait échouer les tests avec un ModuleNotFoundError.

Et le problème de fond n'était ni juridique ni technique. Une place de marché a besoin de logements pour attirer des locataires, et de locataires pour attirer des propriétaires. Ce démarrage à froid était le vrai problème du projet, et il ne se résout pas en écrivant du code.

Ce que j'ai construit : les choix techniques et pourquoi ceux-là

Un back Django avec une app logements, l'authentification par django-allauth, un front React.

J'ai sorti le parser de langage naturel du serveur. Au lieu de charger transformers en local, j'appelle Llama-3.1-8B-Instruct via huggingface_hub.InferenceClient et je récupère du JSON déjà structuré. Ça retire une dépendance lourde et un modèle à héberger pour une fonction qui tourne quelques fois par requête. Le compromis est assumé : je troque une latence maîtrisée contre un appel réseau, et j'accepte une dépendance externe sur un chemin qui n'est pas critique. Sur un chemin critique, j'aurais tranché l'inverse.

Le morceau qui compte, c'est le système de références bidirectionnelles : confirmation de location, demande de référence, messagerie entre les deux parties. C'est mon seul vrai différenciateur face aux plateformes déjà installées. Le reste, les concurrents le font déjà, et le refaire un peu mieux ne fait changer d'habitude à personne.

La contrainte légale, elle, n'a produit aucune ligne de code. Elle a produit une décision d'offre, sur papier. Le pivot conforme consisterait à faire commander la vérification par le candidat lui-même, qui en devient propriétaire et la partage s'il le veut : l'article 1904 est respecté parce que le proprio n'exige rien, et le candidat consent. Le produit changerait de nature au passage, d'énième outil de vérification pour proprio à dossier locataire portable, réutilisable d'un proprio à l'autre, avec la minimisation de données imposée par la CAI comme argument de vente. Cette réécriture est restée classée « pivot lean envisagé » dans mes notes.

Le résultat : ce qui est mesurable et vrai

L'audit growth que j'ai fait passer au projet en avril 2026 est sévère sur les trois axes qui comptent, l'acquisition, l'adéquation au marché et la monétisation. Son diagnostic est écrit noir sur blanc : le piège du dev solo, construire au lieu de vendre. Je l'ai gardé tel quel dans mes notes plutôt que de l'adoucir, parce qu'un audit qu'on réécrit ne sert plus à rien.

Une grille freemium à 0, 29 et 79 dollars a été définie sur papier, jamais branchée à un paiement ni mise en marché.

Une chose a vraiment bougé : le contenu. Le site a atteint 85,9 sur 100 à l'audit SEO du 7 juillet 2026 avec 10 articles, et le mot-clé logement etudiant UQAC s'est tenu entre les positions 4 et 6. C'est la démonstration, pour moi, que la partie contenu de ma chaîne fonctionne quand elle est branchée sur une intention de recherche précise : dix articles bien ciblés suffisent à sortir sur une requête locale, à condition de choisir la requête avant d'écrire.

J'ai retiré le site de mon compte Gridar le 15 juillet 2026 et la génération d'articles s'est arrêtée là. Continuer à publier sur un actif que je n'allais pas défendre aurait coûté du budget d'API pour rien.

Le système de références tourne de bout en bout depuis le 3 août 2026 : confirmation de location, demande de référence et messagerie fonctionnent, validées sur un parcours complet avec des adresses de test en +e2e.

Le projet est gelé depuis le 4 août 2026. C'est un arbitrage, pas un accident de parcours : seul et sans audience, l'effort de vente que je peux fournir est à peu près constant, et chaque front ouvert en parallèle le divise d'autant. Plutôt que d'ajouter des routes à un produit dont je n'avais pas validé la demande, j'ai coupé pour remettre ce temps sur les mandats. Un mandat n'entre pas dans cet arbitrage : il a une date, un périmètre et une entente écrite, et c'est précisément ce qui le distingue d'un projet perso qu'on peut mettre sur pause.

Ce que j'en retiens

J'ai livré plus de 70 routes avant d'avoir validé un seul besoin réel. C'est la mesure exacte de ce que coûte construire avant de vendre, et je ne referais pas ça. Mes propres notes le disent sans se ménager : j'ai continué à empiler des routes au lieu d'aller chercher la demande, et la satisfaction d'avoir livré masquait la seule question qui comptait.

Cette dérive est exactement ce que je ne facture à personne. Sur un mandat, la première route livrée est celle qui prouve la demande, et le reste attend cette preuve. Un client qui me paie n'a pas besoin de 70 routes, il a besoin de celle qui lui ramène un premier oui. C'est aussi pour ça que je découpe un mandat en jalons courts : chaque jalon doit produire quelque chose qu'on peut mettre devant un vrai utilisateur, sinon il ne mérite pas d'exister.

Deuxième leçon, une contrainte réglementaire bien lue vaut mieux qu'une fonctionnalité de plus. L'article 1904 a tué mon modèle de prix initial et m'a donné un angle de produit plus défendable. Je vérifie maintenant le droit local avant d'importer une mécanique qui marche ailleurs, et je le fais au cadrage, pas au lancement, parce qu'une contrainte découverte tard se paie en réécriture.

Troisième, un nom. Deux étiquettes pour un même produit divisent le SEO, la mémoire des gens et les liens entrants. Je choisis la marque avant la première ligne de code.

Je laisse le projet en ligne sur ma page parce que ce qu'il m'a appris est plus utile à un client que ce qu'il aurait rapporté s'il avait marché.