Collecte sur des sources publiques qui n'ont pas d'API, lecture de documents scannés, contrôle qualité, livraison au client. Trois clients réguliers : un cabinet d'avocats en Floride, un investisseur immobilier dans l'Iowa, un expert immobilier en Belgique. Les projets ci-dessous sont décrits sans nommer les clients.
Un investisseur immobilier rachète des maisons en direct dans un comté de l'Iowa. Son problème : identifier les propriétaires susceptibles de vendre avant qu'ils ne passent par une agence — via des signaux publics dispersés dans quatre administrations différentes, qui ne se parlent pas et n'ont aucune API commune.
Dettes fiscales (un PDF annuel du trésorier du comté), ventes aux enchères du shérif (une table publique croisée avec le rapport d'un cabinet), successions (des notices publiées sur un portail départemental), et procédures de saisie (le portail judiciaire de l'État). Chacune produit le même format de fiche en sortie, ce qui permet à toute la suite de la chaîne de les traiter à l'identique.
Pour les procédures de saisie, la première source envisagée s'est révélée fermée à l'accès automatisé, la deuxième ne contenait pas les données attendues. La bonne était le portail judiciaire de l'État : authentification, parcours des numéros de dossier, extraction du détail de chaque affaire.
Le résultat brut n'était toutefois pas exploitable : un dossier judiciaire donne un nom, pas une adresse. Il a fallu croiser chaque défendeur contre le fichier cadastral du comté — 52 942 parcelles — avec une comparaison de noms tolérante aux variantes d'orthographe.
Le seuil de similarité des prénoms, fixé à 0,80. En dessous, on rapproche des gens qui n'ont rien à voir. Au-dessus, on rate les variantes légitimes d'un même prénom. Ce chiffre n'est pas sorti d'une intuition : il a été calibré sur des cas réels du fichier, pour accepter une variante orthographique courante tout en écartant deux prénoms distincts qui se ressemblent.
Après plusieurs mois de construction et de mise au point, 625 prospects ont été poussés dans la chaîne complète, aboutissant à 501 courriers confirmés expédiés. Le système tourne depuis en tâche planifiée quotidienne, avec une maintenance mensuelle et une routine hebdomadaire de rafraîchissement.
Python, Playwright, serveur privé sous Linux, tâches planifiées, orchestration par webhooks, base de déduplication, CRM, service d'impression et d'envoi postal.
Un cabinet d'avocats de Miami avait besoin des jugements nouvellement enregistrés au greffe du comté, sous forme de tableau exploitable. Le portail officiel ne propose ni export, ni API : uniquement des PDF scannés, un par jugement.
La chaîne parcourt le portail, télécharge les documents, en extrait les champs structurés (numéro de dossier, date, montant, créancier, débiteur, avocats de chaque partie) et livre un fichier propre chaque semaine.
En auditant les fichiers déjà livrés, j'ai trouvé un libellé qui posait un vrai problème de fond. Quand aucun avocat n'était mentionné sur le document, la chaîne écrivait « Pro Se / Default » — c'est-à-dire « partie non représentée, jugement par défaut ».
Sauf que ce n'est pas ce que dit le document. L'absence d'avocat listé signifie seulement qu'aucun nom n'apparaît sur ce PDF précis. En déduire un jugement par défaut, c'est ajouter une information juridique que la source ne contient pas — dans un fichier destiné à des avocats, qui vont s'en servir pour décider qui contacter.
« Pro Se / Default » — une conclusion juridique que la source ne permet pas de tirer.
« None listed (unverified) » — ce que le document dit réellement, sans interprétation ajoutée.
Les lignes en erreur étaient livrées telles quelles au client, mêlées aux bonnes données. Il n'y avait aucune reprise sur échec de lecture, aucun tri des documents illisibles, et la clé d'accès au service d'extraction était écrite en dur dans le code.
La version corrigée réessaie avec une temporisation progressive, met les documents problématiques en quarantaine dans un onglet séparé, marque les lignes douteuses au moment de l'extraction plutôt qu'après coup, et lit sa clé depuis l'environnement. Le nombre de traitements simultanés a aussi été réduit, pour cesser de saturer le service en face.
Le premier lot passé dans la version corrigée : 480 jugements, zéro document en quarantaine, zéro ligne signalée douteuse.
Python, lecture automatisée de documents scannés, contrôle qualité intégré, livraison hebdomadaire récurrente.
Un expert immobilier indépendant, seul dans sa structure, passait un temps considérable sur des tâches qui n'étaient pas son métier. Trois outils ont été livrés en plusieurs lots.
Il compilait ses rapports d'état des lieux dans un traitement de texte, photo par photo, pièce par pièce. Sur un dossier réel : 413 photos, 106 pages, une à deux heures de mise en page — et un fichier de 99 Mo, trop lourd pour partir par mail.
Le script prend le dossier de photos tel qu'il sort du téléphone et produit le PDF fini en quelques secondes : tri automatique, une section par pièce, rotation corrigée, format Apple pris en charge, poids ramené autour de 8 Mo sans perte visible. Lanceur simple sous Windows et sous Mac, aucune ligne de commande à taper.
Ses tarifs vivaient à plusieurs endroits, et finissaient immanquablement par diverger. Un simulateur public et le module de calcul interne lisent désormais la même grille, que le client modifie lui-même : un seul prix à mettre à jour, jamais deux tarifs contradictoires en circulation.
Un outil existant devait repérer les annonces immobilières publiées par des particuliers plutôt que par des agences. Il se trompait, et surtout il ne le disait pas : les erreurs étaient avalées sans aucun message.
Le plus beau bug tenait en trois lettres. Le filtre cherchait le mot « era » (le nom d'un réseau d'agences) — et le trouvait dans « utilisera », présent dans le texte légal standard affiché en bas de chaque annonce du site. Résultat : des annonces de particuliers écartées à tort, en silence, depuis le début.
Chaque correctif a été validé par une manœuvre simple : corriger, écrire le test, puis réintroduire volontairement le bug pour confirmer que le test l'attrapait bien — avant de restaurer la bonne version. Un test qui n'a jamais échoué ne prouve rien.
La suite compte aujourd'hui 56 tests couvrant l'ensemble de la chaîne, y compris les parties qui n'avaient jamais été testées du tout, comme le remplissage du formulaire de contact.
Python, traitement d'image, génération de PDF, automatisation de navigateur, suite de tests automatisés.
Un script qui affiche « terminé, aucune erreur » ne dit pas ce que le destinataire va recevoir. Entre les deux, il y a toute la place nécessaire pour un bug. Je vais regarder le document produit avant de dire que c'est fini — cette habitude m'a déjà évité d'envoyer soixante-trois courriers dont le texte débordait de la page.
Plutôt que d'annoncer une grosse livraison lointaine, je livre des morceaux qui fonctionnent. Vous voyez quelque chose tourner tôt, et vous corrigez le tir pendant qu'il est encore temps de le faire sans douleur.
Quand une piste est un cul-de-sac, quand une donnée n'est pas fiable, quand une estimation était fausse — je le dis, avec le chiffre exact. C'est moins agréable sur le moment que de livrer quelque chose de fragile, et bien plus confortable trois mois plus tard.
Python pour l'essentiel, avec JavaScript, PHP et SQL selon les besoins.
Playwright et DrissionPage pour les sources sans API, lecture de documents scannés, déduplication, géocodage.
n8n auto-hébergé, Make, tâches planifiées, webhooks, intégrations d'API REST.
API Claude et Gemini pour le traitement de texte et de documents, RAG sur données métier, agents vocaux.
Docker, serveurs privés sous Linux, SQLite et PostgreSQL, Git.
Je vous dis si c'est automatisable, comment, et à quel coût — y compris quand la réponse est que ça n'en vaut pas la peine. Missions à distance, France et international.