Le fenêtrage est le mécanisme, non l'affirmation du modèle

Une lecture de l'Architecte Honnête de A Tutorial on GeoAI: Designing Footprint Extraction from NAIP Imagery Using U-Net, Grounding DINO, SAM, and Mask R-CNN, publié le 2026-08-02 par Sana Hassan sur Marktechpost.

L'affirmation de surface de l'article est un tutoriel : un pipeline de bout en bout qui transforme des images aériennes NAIP brutes en polygones d'empreintes de bâtiments, utilisant quatre modèles (U-Net, Grounding DINO, SAM, Mask R-CNN) sur douze étapes. L'Architecte Honnête le lit pour le mécanisme sous le tutoriel, et en trouve six. Celui qui porte la charge est le fenêtrage : le modèle s'entraîne sur des puces de 512 pixels mais infère sur une scène complète en glissant une fenêtre de 512 pixels avec 256 pixels de chevauchement. Le modèle est la couche marketing ; le fenêtrage est la couche mécanisme. Le Theorem 3 dans le HAI Engine d'Everythink affirme la même forme : une propriété est garantie exactement lorsque son mécanisme est implémenté et mesurant. Ici la propriété est « un modèle entraîné sur des puces couvre une scène arbitrairement grande » ; le mécanisme est « une fenêtre glissante avec chevauchement, tuilant la scène en patchs d'inférence de la taille d'une puce. »

Ce post extrait six formes de mécanisme du tutoriel Marktechpost, applique le Theorem 3 à chacune et trace des parallèles transversaux à la plateforme Everythink. Chaque parallèle depuis notre plateforme est marqué ⚠️ — Everythink opère en prévision civile et défensive, le tutoriel Marktechpost opère en éducation GeoAI pour développeurs, donc le parallèle est structurel, non une affirmation que nos systèmes servent le même marché. Les six formes de mécanisme elles-mêmes sont ✅ — elles sont extractibles de la propre évidence du tutoriel.

Mécanisme 1 — L'inférence par fenêtre glissante est le mécanisme de grande scène

Le tutoriel applique geoai.semantic_segmentation à la scène de test avec window_size=512 et overlap=256. L'Architecte Honnête lit cela comme une affirmation de mécanisme : un modèle entraîné sur des puces couvre une scène arbitrairement grande en glissant une fenêtre avec chevauchement, non en entraînant un modèle plus grand. Le mécanisme qui produit « couverture de scène complète depuis un modèle entraîné sur des puces » est la fenêtre glissante avec chevauchement, non la capacité du modèle. Le modèle ne voit jamais la scène complète pendant l'entraînement ; le fenêtrage lui permet d'inférer sur la scène complète au moment de l'inférence. ✅ Production — le tutoriel nomme le mécanisme (fenêtre glissante, 512px, 256px de chevauchement) et la propriété (prédiction de scène complète).

Le tutoriel est honnête que le chevauchement est un compromis, non un paramètre gratuit. Un chevauchement plus grand produit des limites de tuile plus lisses mais coûte plus de temps d'inférence ; un chevauchement plus petit est plus rapide mais produit des artefacts de limite. Le fenêtrage achète la couverture ; il coûte du temps d'inférence proportionnel au chevauchement.

Le parallèle transversal au World Monitor d'Everythink est uniquement structurel. World Monitor route les geo-signaux par préfixe de geohash — chaque client reçoit les deltas seulement pour les tuiles de son viewport, non la planète entière. Le « glisse une fenêtre de 512px à travers la scène » du tutoriel Marktechpost et le « route par préfixe de geohash » de World Monitor partagent la même forme : le monde est traité en tuiles, non comme une entrée monolithique. ⚠️ Partiel — le parallèle est structurel ; World Monitor sert la livraison de geo-signaux civils et défensifs, la fenêtre glissante de Marktechpost sert l'éducation GeoAI. Domaines différents, même forme : tuile le monde, traite par tuile.

Mécanisme 2 — La génération de puces et de masques est le mécanisme de données d'entraînement

Le tutoriel utilise geoai.export_geotiff_tiles avec tile_size=512, stride=256 et all_touched=True pour diviser l'image source en puces géoréférencées chevauchantes et créer des masques raster correspondants. L'Architecte Honnête lit cela comme une affirmation de données d'entraînement : un dataset entraînable à partir d'une grande image et d'étiquettes vectorielles est garanti par la génération de paires puce + masque avec géoréférencement préservé, non par étiquetage manuel. Le mécanisme qui produit « un dataset sur lequel le modèle peut s'entraîner » est la paire puce + masque avec CRS préservé, non les étiquettes seules. Sans géoréférencement, les puces perdent leur contexte spatial ; avec lui, chaque puce porte sa position sur la planète. ✅ Production — le tutoriel nomme le mécanisme (geotiff tiles, stride, all_touched) et la propriété (puces d'entraînement géoréférencées).

Le tutoriel est honnête que la génération de puces est un souci d'échantillonnage, non un souci d'étiquetage. Le drapeau skip_empty_tiles=False signifie que le dataset inclut des puces sans bâtiments, ce qui est nécessaire pour que le modèle apprenne la classe de fond. Un modèle de segmentation de bâtiments qui ne voit jamais de puces vides sur-prédira les bâtiments.

Le parallèle transversal au « the space is the router » d'Everythink est uniquement structurel. La topologie d'Everythink est réseau → communauté → salle : chaque salle est un contexte spatialement délimité, et la clé de routage est la position. Le « chaque puce porte sa position géoréférencée » du tutoriel Marktechpost et le « chaque salle porte sa position topologique » d'Everythink partagent la même forme : la clé spatiale est préservée à travers le pipeline de traitement. ⚠️ Partiel — le parallèle est structurel ; la topologie d'Everythink sert la prévision civile et défensive, le géoréférencement de Marktechpost sert l'éducation GeoAI. Domaines différents, même forme : la position est la clé de routage, préservée à travers le pipeline.

Mécanisme 3 — L'IoU de validation est le mécanisme de sélection de modèle

Le tutoriel utilise save_best_only=True avec early_stopping_patience=5 et identifie « l'époque qui produit le plus haut IoU de validation » comme le meilleur checkpoint. L'Architecte Honnête lit cela comme une affirmation de sélection de modèle : le meilleur checkpoint est garanti par la métrique d'IoU de validation, non par la perte d'entraînement. Le mécanisme qui sélectionne le meilleur modèle est l'IoU de validation, non la perte d'entraînement. Le tutoriel est explicite : « perte de validation montant tandis que la perte d'entraînement descend => surapprentissage ; les deux plates et hautes => sous-apprentissage. » ✅ Production — le tutoriel nomme le mécanisme (IoU de validation, early stopping, save best only) et la propriété (meilleur checkpoint sélectionné).

Le tutoriel est honnête que l'IoU de la classe bâtiment est le nombre qui compte, non l'IoU de fond. Le tutoriel affirme : « l'IoU de fond est gonflé par l'énorme classe négative et semble toujours super. » Une métrique gonflée par le déséquilibre de classes n'est pas le mécanisme de sélection ; l'IoU de la classe bâtiment l'est.

Le parallèle transversal à l'Oracle d'Everythink est uniquement structurel. L'Oracle normalise les probabilités en exactement un endroit et estampille l'entropie en nats sur chaque fusion — la lecture d'entropie est le signal de calibration qui dit aux consommateurs combien faire confiance à l'ensemble. Le « l'IoU de la classe bâtiment est le nombre qui compte » du tutoriel Marktechpost et le « l'entropie en nats est le signal de calibration » de l'Oracle partagent la même forme : la métrique qui n'est pas gonflée par la classe dominante est le signal de confiance. ⚠️ Partiel — le parallèle est structurel ; l'Oracle sert la prévision civile et défensive, l'IoU de validation de Marktechpost sert l'éducation GeoAI. Domaines différents, même forme : la métrique non corrompue par la classe majoritaire est la porteuse de sélection et calibration.

Mécanisme 4 — La régularisation de masque à polygone est le mécanisme de vectorisation

Le tutoriel convertit les masques prédits en polygones de bâtiments via un pipeline en quatre étapes : regiongroups (supprimer les petites régions bruitées, min_size=50), raster_to_vector (polygoniser, min_area=15, simplify_tolerance=0.5), orthogonalize (imposer des angles droits, epsilon=1.5) et regularization (simplifier, angle_tolerance=12). L'Architecte Honnête lit cela comme une affirmation de vectorisation : des polygones de bâtiments propres depuis un masque raster bruité sont garantis par le pipeline de régularisation, non par le modèle de segmentation seul. Le mécanisme qui produit « des limites de bâtiments propres » est la régularisation en quatre étapes, non la précision au niveau pixel du modèle. Un modèle avec un IoU de pixel parfait produit encore des polygones irréguliers sans régularisation. ✅ Production — le tutoriel nomme le mécanisme (regiongroups, raster_to_vector, orthogonalize, regularization) et la propriété (polygones de bâtiments propres).

Le tutoriel est honnête que la régularisation est un souci de géométrie, non un souci d'apprentissage profond. Le paquet buildingregulariser impose des angles droits sur les empreintes de bâtiments — une contrainte que le modèle de segmentation ne connaît pas. Le modèle produit des pixels, le régulariseur produit des polygones, et aucun ne subsume l'autre.

Le parallèle transversal aux ports hexagonaux basés sur traits d'Everythink est uniquement structurel. L'architecture d'Everythink sépare les préoccupations en ports où chaque port répond à une question différente, et les crates de cas d'usage dépendent du trait, jamais de l'adaptateur concret. Le « le modèle produit des pixels, le régulariseur produit des polygones, chacun est une étape séparée » du tutoriel Marktechpost et le « chaque port répond à une question différente, le trait est le contrat » d'Everythink partagent la même forme : la séparation des préoccupations est le mécanisme, et aucune étape unique ne subsume les autres. ⚠️ Partiel — le parallèle est structurel ; les ports d'Everythink servent la prévision civile et défensive, le pipeline de régularisation de Marktechpost sert l'éducation GeoAI. Domaines différents, même forme : sépare les préoccupations, chacune avec son propre mécanisme.

Mécanisme 5 — La segmentation zero-shot par invites textuelles est le mécanisme sans entraînement

Le tutoriel applique Grounding DINO et SAM avec des invites textuelles ["building", "house", "rooftop"] pour réaliser une segmentation zero-shot de bâtiments sans entraînement additionnel du modèle. L'Architecte Honnête lit cela comme une affirmation sans entraînement : la segmentation de bâtiments sans entraînement personnalisé est garantie par des invites textuelles à un modèle fondamental, non par un U-Net entraîné. Le mécanisme qui produit « segmentation sans entraînement » est l'invite textuelle à un modèle fondamental pré-entraîné, non le dataset étiqueté. ✅ Production — le tutoriel nomme le mécanisme (Grounding DINO + SAM, invites textuelles) et la propriété (segmentation zero-shot).

Le tutoriel est honnête que le zero-shot est un paradigme différent, non un repas gratuit. L'approche zero-shot produit des « objets trouvés » qui peuvent différer en compte et en qualité de la sortie du U-Net entraîné. Le zero-shot achète le sans-entraînement ; il coûte la précision et le contrôle.

Le parallèle transversal aux Sisters typées d'Everythink est uniquement structurel. Chaque Sister est une personnalité typée — analyst, contrarian, disruptor, historian, institutionalist — typée pour une posture de raisonnement, et le type est le tampon de provenance sur chaque sortie. Le « les invites textuelles dirigent le modèle fondamental vers les bâtiments » du tutoriel Marktechpost et le « les personnalités typées dirigent chaque Sister vers une posture de raisonnement » d'Everythink partagent la même forme : l'invite ou le type est le mécanisme de direction, et le modèle pré-entraîné ou la personnalité produit la sortie. ⚠️ Partiel — le parallèle est structurel ; les Sisters typées servent la prévision civile et défensive, les invites textuelles de Grounding DINO + SAM servent l'éducation GeoAI. Domaines différents, même forme : l'invite est le mécanisme de direction, le modèle pré-entraîné est le producteur.

Mécanisme 6 — Segmentation sémantique vs instance est le mécanisme de question en aval

Le tutoriel compare la segmentation sémantique U-Net avec la segmentation d'instance Mask R-CNN et affirme : « Des comptes différents sont attendus : U-Net fusionne les toits adjacents, Mask R-CNN les sépare en instances. Choisissez le paradigme qui correspond à votre question en aval. » L'Architecte Honnête lit cela comme une affirmation de sélection : le bon paradigme de segmentation est garanti en faisant correspondre le paradigme à la question en aval, non en choisissant le score de précision le plus élevé. Le mécanisme qui produit le bon choix est la correspondance de question en aval, non la comparaison d'IoU. Un IoU plus élevé ne fait pas de la segmentation sémantique le bon choix si la question en aval a besoin de comptes d'instances. ✅ Production — le tutoriel nomme le mécanisme (faire correspondre le paradigme à la question en aval) et le compromis (fusionner vs séparer).

Le tutoriel est honnête qu'aucun paradigme n'est universellement supérieur. U-Net fusionne les toits adjacents en un masque ; Mask R-CNN les sépare en instances. Le bon paradigme dépend de si la question en aval demande « où sont les bâtiments ? » (sémantique) ou « combien de bâtiments ? » (instance). Il n'y a pas de gagnant global : le paradigme est sélectionné par la question, non par la métrique.

Le parallèle transversal au HAI Engine d'Everythink est uniquement structurel. Le HAI Engine fait tourner une décennie de Sisters typées qui produisent des sorties différentes, et l'Oracle les fusionne en un ensemble calibré — la fusion est le mécanisme, et la diversité des Sisters est l'entrée. Le « U-Net fusionne, Mask R-CNN sépare, choisis par question en aval » du tutoriel Marktechpost et le « les Sisters produisent des prévisions différentes, l'Oracle fusionne, la fusion est le mécanisme » d'Everythink partagent la même forme : le paradigme (fusionner ou séparer) est sélectionné par la question en aval, et la diversité des producteurs est l'entrée. ⚠️ Partiel — le parallèle est structurel ; la fusion de l'Oracle sert la prévision civile et défensive, la sélection de paradigme de Marktechpost sert l'éducation GeoAI. Domaines différents, même forme : le paradigme est la correspondance de question en aval, la diversité est l'entrée.

Ce que cela implique pour la portée et les limites

Le tutoriel Marktechpost concerne l'éducation GeoAI pour développeurs. La plateforme d'Everythink concerne la prévision civile et défensive. Les parallèles transversaux dans ce post sont structurels — ils partagent des formes de mécanisme, non des marchés. L'Architecte Honnête marque les parallèles ⚠️ pour cette raison.

Le propre go-to-market d'Everythink pour les outils GeoAI commerciaux est 🔵 Roadmap — la plateforme est pré-revenu, et toute application commerciale des parallèles tracés ici est soumise à cet état Roadmap et à l'examen Howey avant de pouvoir être offerte. Les parallèles architecturaux tiennent indépendamment ; les affirmations commerciales non.

Ce que le tutoriel n'affirme pas mérite aussi une marque. Il n'affirme pas que U-Net est supérieur à Mask R-CNN — il nomme le compromis fusionner-vs-séparer. Il n'affirme pas que le zero-shot est supérieur à l'entraînement personnalisé — il nomme le coût de précision. Il n'affirme pas que la régularisation est optionnelle — il nomme le pipeline en quatre étapes. Ces limites de portée sont l'honnêteté du tutoriel, et ce post les préserve.

Points clés

• La couverture de scène complète depuis un modèle entraîné sur des puces est garantie par une fenêtre glissante avec chevauchement, non par un modèle plus grand. Le fenêtrage est le mécanisme de couverture. ✅ Production.
• Un dataset entraînable à partir d'une grande image est garanti par la génération de paires puce + masque avec géoréférencement préservé. La paire puce + masque est le mécanisme de données d'entraînement. ✅ Production.
• Le meilleur checkpoint est garanti par l'IoU de validation de la classe bâtiment, non par la perte d'entraînement ou l'IoU de fond. La métrique non gonflée est le mécanisme de sélection. ✅ Production.
• Des polygones de bâtiments propres depuis un masque bruité sont garantis par le pipeline de régularisation en quatre étapes, non par le modèle de segmentation seul. La régularisation est le mécanisme de vectorisation. ✅ Production.
• La segmentation de bâtiments sans entraînement personnalisé est garantie par des invites textuelles à un modèle fondamental. L'invite est le mécanisme sans entraînement. ✅ Production.
• Le bon paradigme de segmentation est garanti en faisant correspondre le paradigme à la question en aval. La question en aval est le mécanisme de sélection. ✅ Production.
• Les parallèles transversaux au World Monitor d'Everythink (tuile le monde, traite par tuile), « the space is the router » (la position est la clé de routage), entropie de l'Oracle (la métrique non gonflée est le signal de confiance), ports hexagonaux (sépare les préoccupations, chacune avec son propre mécanisme), Sisters typées (l'invite est le mécanisme de direction) et HAI Engine (le paradigme est la correspondance de question en aval) sont uniquement structurels — marchés différents, mêmes formes de mécanisme. ⚠️ Partiel.
• Le go-to-market d'Everythink pour les outils GeoAI commerciaux est 🔵 Roadmap — pré-revenu, soumis à l'examen Howey ; les parallèles architecturaux tiennent, les affirmations commerciales non.

Sources

• Sana Hassan, A Tutorial on GeoAI: Designing Footprint Extraction from NAIP Imagery Using U-Net, Grounding DINO, SAM, and Mask R-CNN, Marktechpost, publié le 2026-08-02. https://www.marktechpost.com/2026/08/02/a-tutorial-on-geoai-designing-footprint-extraction-from-naip-imagery-using-u-net-grounding-dino-sam-and-mask-r-cnn/ (récupéré le 2026-08-23).
• Architecture de la plateforme Everythink : HAI Engine en production depuis 2016 ; Theorem 3 (une propriété est garantie exactement lorsque son mécanisme est implémenté et mesurant) ; topologie « the space is the router » (réseau → communauté → salle) ; World Monitor (geo-signaux routés par préfixe de geohash, les clients lisent le cache non les upstreams) ; normalisation de l'ensemble de l'Oracle avec entropie en nats estampillée sur chaque fusion ; Sisters typées (analyst, contrarian, disruptor, historian, institutionalist) retournant SisterOutput ; ports hexagonaux basés sur traits avec adaptateurs échangeables ; souveraineté de l'Eye Key (HMAC et empreinte enregistrés, le texte clair ne touche jamais le disque).