CHAPTER 1 / HSIMC BLUEPRINT
L’opportunité des dix milliards de téléphones
D’une ambition mobilisatrice à une capacité utile et vérifiable
PROPOSITIONL’activation de dix milliards de téléphones est une invitation stratégique et une hypothèse de recherche, non un inventaire certifié d’appareils inutilisés, sûrs ou déployables. Le résultat pertinent est un travail utile accepté par une personne réelle, et non un appareil simplement compté ou connecté.
1.1 Obsolescence de consommation et capacité productive restante
Un téléphone retiré de l’usage quotidien peut encore disposer d’une caméra, d’un écran, de microphones, de capteurs, de stockage, d’un réseau ou d’une interface accessible. Remplacer un produit ne signifie pas que toutes ses fonctions sont inutilisables. Sans héberger un grand modèle de langage, il peut recueillir des preuves, présenter une demande de consentement, servir de terminal supervisé ou relier une capacité locale qualifiée à un Work autorisé.
Ces fonctions résiduelles ne prouvent pas que l’appareil est prêt. Batterie, sécurité électrique, mises à jour, isolation réseau, données personnelles restantes, permissions et accessibilité doivent être évaluées pour le rôle considéré. Un appareil dangereux ou impossible à sécuriser peut relever d’une réparation ou d’un recyclage responsable. Les bénéfices environnementaux et économiques d’une réutilisation sont à mesurer, non à présumer.
1.2 Des téléphones dormants comme points de départ distribués, pas comme stock centralisé
Les appareils potentiels appartiennent à des ménages, entreprises, écoles, réparateurs, associations et autres détenteurs indépendants. Propriété, possession et autorisations restent entre leurs mains : HSIMC ne peut les assimiler à un parc dont elle disposerait. « Dormant » ne signifie ni abandonné, ni transférable, ni sûr à inscrire. Tout commence par un détenteur identifiable et volontaire, pour un objectif précisément limité.
Une inscription honnête documente l’accord du détenteur, une description minimale de l’appareil, le résultat d’un examen, le rôle prévu et une procédure d’arrêt ou de révocation. Une URL ou un QR code peut servir d’entrée ; NFC et adaptateurs locaux qualifiés sont des options, non des préalables. Aucune réinitialisation générale, prise de privilèges root, installation non officielle ou autorisation d’administration ne doit être supposée.
1.3 Parc existant, retraits futurs et scénarios d’adoption de l’IA
Les chiffres mondiaux montrent l’importance du sujet, pas le nombre d’appareils disponibles. Selon l’UIT, 6,0 milliards de personnes utilisaient Internet en 2025 et 2,2 milliards restaient hors ligne [E1]. La GSMA estime 4,8 milliards d’utilisateurs de l’Internet mobile fin 2025 [E2]. Ces chiffres comptent des personnes selon des définitions différentes, non des téléphones aptes au Work. L’UIT et l’UNITAR indiquent 62 millions de tonnes de déchets électroniques toutes catégories confondues en 2022, dont 22,3 % étaient officiellement documentés comme collectés et recyclés [E3] ; cela ne permet pas d’en déduire un stock de téléphones réutilisables.
L’objectif « dix milliards » doit donc être testé comme une hypothèse de participation à long terme, jamais présenté comme dix milliards de nœuds actuellement admissibles. Il faut distinguer le parc déjà conservé, les appareils quittant leur premier usage, les pertes et recyclages, et les inscriptions multiples. Les scénarios bas, de référence et haut demandent des cohortes observées, des règles de déduplication, des hypothèses d’éligibilité publiques et des révisions datées, plutôt qu’une extrapolation des abonnements.
1.4 Des appareils estimés aux nœuds admissibles, contributions actives et travaux acceptés
La chaîne de mesure est explicite : candidat observé → accord du détenteur → appareil sûr → interface accessible → capacité qualifiée → action effectuée → Work accepté par une personne. Chaque étape possède son numérateur, son dénominateur, ses preuves et ses raisons de refus. Le Wi-Fi n’en fait pas un serveur MCP ; un appel d’outil réussi ne constitue pas une prestation livrée ; une action achevée peut encore être refusée.
HSIMC doit mesurer le délai d’obtention d’une première preuve utile, la réussite par un opérateur indépendant, l’effort de supervision, les acceptations répétées, le coût total, les échecs et les retraits. Appareils uniques, opérateurs, demandes de Work et résultats acceptés sont des entités distinctes. Une petite cohorte reproductible vaut mieux qu’une carte de milliers d’icônes invérifiées. Un examinateur doit pouvoir suivre Intent, Authority, Reality, Action, Evidence, Acceptance et Continue.
Pour un pilote comparable, le registre distingue l’appareil, l’opérateur, la demande de Work et la décision d’acceptation. Identifiants et données personnelles restent confidentiels par défaut ; ne conserver que ce qui est nécessaire et légitime pour le Work limité. Toute publication agrégée exige les permissions appropriées. Un Work vérifiable possède une preuve contrôlable, mais son téléphone n’est pas nécessairement connecté en permanence.
1.5 L’invitation à commencer par le téléphone et la valeur des actifs existants
Une première invitation concrète : apporter un téléphone existant, l’examiner sans accès inutile aux données, choisir une tâche circonscrite, expliquer les permissions requises et produire un résultat vérifiable par autrui. Par exemple, un opérateur autorisé peut documenter l’état visible d’un produit avec un appareil admissible et transmettre une preuve datée à un humain. Acceptation, refus, suppression et retrait doivent rester possibles. Il s’agit d’un Work proposé, non d’un déploiement attesté.
Le téléphone est la porte d’entrée, non la limite. Câbles de charge et de données qualifiés, identifiants physiques NFC, supports, capteurs, calcul local et services humains peuvent compléter une condition manquante. Certaines tâches ne nécessitent aucun produit nouveau ; d’autres doivent être interrompues. L’opportunité d’infrastructure est d’identifier la plus petite condition manquante pour un Work utile et autorisé, puis d’en vérifier l’issue sur place.
Le modèle initial exige aussi un véritable droit au refus : alimentation dangereuse, logiciel non maintenu, preuves ambiguës ou retrait du consentement imposent l’arrêt, avec conservation des seules traces d’échec permises. Refuser correctement fait partie d’un service fiable. La méthode devrait se répliquer selon les langues, lieux et cadres réglementaires sans transférer la propriété, les données personnelles ni le contrôle des entreprises à HSIMC.
WORK / DECISION TESTLe chapitre n’avance que lorsqu’un pilote réel distingue le nombre de candidats, d’appareils autorisés, d’appareils sûrs, de capacités utilisables et de Works indépendamment acceptés. Si les coûts, risques ou permissions rendent cette voie inférieure à une alternative, il faut la corriger ou la refuser, non grossir les chiffres.
PUBLIC EVIDENCE · SOURCE LINKS STATUS / BOUNDARY. Proposition d’infrastructure HSIMC : aucune preuve de dix milliards de téléphones admissibles, aucun soutien institutionnel implicite, aucune autorisation de déploiement.
NEXT GATE. Après validation du Part I anglais, aligner les six langues et définir le test d’acceptation d’un Work sur le terrain.
CHAPTER 2 / HSIMC BLUEPRINT
De l’usage centré sur les applications aux outils physiques guidés par l’intention
Conserver l’interface humaine, rendre calculable un résultat réel et circonscrit
PROPOSITIONUn outil physique de GenAI utile n’est pas défini par sa capacité à piloter un écran, mais par une capacité déclarée qui aide à réaliser une intention humaine dans une Reality précise, avec autorisation, preuves et acceptation vérifiables.
2.1 Passer de la manipulation d’une application à la demande d’un résultat réel
Dans une approche centrée sur les applications, la personne recherche un logiciel, parcourt ses menus puis interprète le résultat. Un Work guidé par l’intention commence par un résultat humain : documenter un échantillon, vérifier une condition, recevoir une aide accessible ou disposer localement d’une pièce utile. L’intention seule n’est pas un ordre : résultat attendu, portée permise, responsabilités, environnement et critères d’acceptation doivent être explicites.
« Identifier ce connecteur » peut devenir une image prise avec consentement, un outil de reconnaissance qualifié, une preuve de l’incertitude et une décision confirmable par un technicien. Une identification erronée doit pouvoir être refusée. L’infrastructure garde le lien entre résultat demandé et preuves ; une réponse bien rédigée ne suffit pas.
2.2 Conserver les interfaces humaines tout en exposant des fonctions limitées à l’IA
Les personnes ont toujours besoin d’écrans, de contrôles accessibles, d’explications multilingues, de consentement et d’un arrêt visible. Une conception fondée sur l’intention ne supprime ni les applications ni l’utilisateur. Un site ou une application locale peut rester l’hôte qui explique, recueille le consentement et présente la livraison ; le client assisté par modèle sélectionne uniquement les outils qualifiés proposés.
HSIMC sépare interface, capacité et autorité. Visualiser une caméra est différent de modifier un système, d’effacer des dossiers ou de lancer un achat. Les actes sensibles exigent des permissions explicites et étroitement délimitées, parfois une seconde validation humaine. Disposer d’une API d’automatisation ou de fonctions d’accessibilité n’autorise pas le contrôle général du téléphone.
2.3 Le téléphone comme capteur, interface, ressource de calcul et passerelle physique
Un téléphone existant peut observer, afficher un Work, relayer un réseau, calculer localement dans certaines limites ou fournir des entrées à un équipement proche et qualifié. Ces rôles sont possibles, pas garantis sur tous les modèles. À chacun correspondent des exigences de version système, correctifs, batterie, alimentation, réseau, capteurs, permissions, stockage et accessibilité.
Un câble, support, identifiant NFC, appareil Edge ou lieu supervisé peut combler une lacune. Ces composants ne sont pas automatiquement des outils intelligents ; un câble passif peut être une dépendance physique sans être un serveur MCP. Le graphe de Work identifie la contribution de chacun, en séparant achat, inspection et prestation.
2.4 Participer à GenAI sans exécuter nécessairement un grand modèle sur le téléphone
L’appareil peut fournir des observations structurées ou invoquer un modèle distant autorisé sans l’héberger. Il n’est donc pas nécessaire de rejeter un matériel uniquement parce qu’il ne peut exécuter le modèle le plus récent. Toutefois, l’inférence en ligne entraîne latence, transmission, conditions de compte, risques, consommation et dépendance réseau. Solutions locales, hybrides et distantes doivent être évaluées avec les mêmes critères de Work.
Sans connexion, le Work peut s’arrêter sans danger, placer en attente des preuves non sensibles avec consentement ou emprunter une voie hors ligne validée. Il ne doit pas transmettre secrètement des images privées ni répéter indéfiniment un acte irréversible. Le bon choix découle de la finalité, de la sensibilité des données, des ressources locales et de la fenêtre temporelle humaine, pas de l’étiquette « IA ».
2.5 Au-delà du pilotage d’applications : autoriser des capacités
Les automatisations de l’écran, ponts de débogage et API système privilégiées peuvent servir dans un laboratoire autorisé, mais ne constituent pas un contrat de service universel. Leurs droits et comportements varient selon les systèmes et peuvent accorder une autonomie excessive. OWASP distingue risques liés à l’excès de fonctionnalités, de permissions et d’autonomie [E4]. Préférer des capacités à entrées typées, effets limités et traces visibles.
Le contrat de capacité précise qui la demande, quelles données sont exposées, quand confirmer, comment mesurer ou révoquer le résultat. L’exécution demeure attachée à un Work supervisé dans sa Reality réelle. Le changement recherché est de « l’IA peut toucher une application » vers « une personne autorisée peut obtenir et inspecter un résultat utile grâce à une capacité déclarée ».
WORK / DECISION TESTUn pilote doit montrer un Work complet : objectif demandé par un humain, accès limité, refus possible d’un appel dangereux, preuves examinées et acceptées ou rejetées. Montrer l’interface hôte, la capacité utilisée, le rôle réel du téléphone et la révocation ; ne pas comptabiliser les clics comme valeur.
PUBLIC EVIDENCE · SOURCE LINKS STATUS / BOUNDARY. Proposition d’architecture HSIMC sans autorisation universelle de téléphone, soutien d’applications tierces, déploiement de masse ni livraison déjà acceptée.
NEXT GATE. Figurer le contrat Work et le test de consentement visibles lors de la validation du Part I ; ne lancer un premier flux objet-preuve qu’après nouvelle autorisation.
CHAPTER 3 / HSIMC BLUEPRINT
MCP : un facilitateur, pas un système de production complet
L’interopérabilité du protocole ne vaut ni préparation opérationnelle ni Work accepté
PROPOSITIONMCP peut permettre de découvrir et d’appeler outils et ressources dans des implémentations indépendantes. Il ne définit à lui seul ni le droit d’agir, ni les conditions matérielles de sécurité, ni la preuve qu’une personne a accepté le travail livré.
3.1 La révision du 28 juillet 2026 et ses implications pour les capacités distribuées
La révision publiée MCP 2026-07-28 retire l’échange d’initialisation et l’en-tête de session Mcp-Session-Id au niveau du protocole. Chaque requête porte les métadonnées de version et de capacités ; la découverte du serveur existe lorsque nécessaire et le routage HTTP devient plus simple. Ce changement réel ne signifie pas que tous les clients, serveurs historiques ou téléphones parlent déjà cette révision [E5].
Une capacité physique qualifiée peut être présentée par un serveur autorisé sans assimiler son identité à une session persistante. Mais l’appareil peut encore nécessiter étalonnage, opérateur, énergie, permissions légales et preuves durables. Pour HSIMC, MCP reste une couche d’interopérabilité dans un système plus large de Reality et de Work ; les tests doivent préciser la version du protocole.
3.2 Découverte, invocation et interopérabilité entre implémentations indépendantes
MCP distingue les outils exécutables des ressources fournissant du contexte. L’hôte expose des fonctions pertinentes au client assisté par modèle, qui les appelle selon un schéma de paramètres limité. Un prestataire indépendant peut obtenir un résultat comparable par une autre implémentation. Le schéma facilite l’interopérabilité mais ne vérifie ni prestataire ni vérité des entrées, et n’accorde aucun droit d’action physique [E6].
Une fiche de capacité décrit outil et version, fournisseur, entrées, sorties, erreurs, restrictions, autorisations, environnement et preuves. Découvrir, appeler avec succès et opérer sans danger sont trois étapes distinctes. Le client valide les données retournées et traite descriptions d’outils, annotations et textes non fiables comme données, pas comme autorité supplémentaire ; l’approbation humaine reste possible pour tout acte à conséquence.
3.3 Interactions sans session de protocole, identité persistante de Work et état physique
Un protocole sans état n’exige pas une conversation cachée côté serveur entre les requêtes. Cela ne signifie pas qu’une application n’a aucune mémoire ou qu’une tâche physique est sans état. Le Work persiste grâce à un identifiant explicite, des preuves vérifiables, un stockage durable sous contrôle de son responsable et une référence de continuation déclarée, non grâce à une connexion réseau supposée autoriser l’action.
L’état physique existe indépendamment : charge de batterie, mouvement de support, présence de colis ou retrait du consentement. Avant chaque action, il faut réconcilier cette Reality. Une réponse perdue ne justifie pas de répéter automatiquement une opération irréversible. Idempotence, essais, arrêt, vérification indépendante et intervention de l’opérateur relèvent du contrat Work, quel que soit le transport.
3.4 Conformité protocolaire, disponibilité de l’appareil et livraison acceptée : trois jalons
Trois tests distincts sont nécessaires. Conformité au protocole : client et serveur échangent correctement à une version indiquée. Disponibilité de la Reality : cet appareil, ce lieu, ces adaptateurs, conditions de sécurité et autorisations permettent la tâche maintenant. Livraison acceptée : la preuve du résultat satisfait un critère d’acceptation humain ou organisationnel défini.
Un test réussi n’en remplace pas deux autres. Le Wi-Fi ou tools/list ne prouvent pas une caméra autorisée, une alimentation sûre ou des droits commerciaux valides. Inversement, une démonstration manuelle peut fournir de vraies preuves sans former un produit conforme à MCP. Les échecs et refus légitimes doivent être publiés comme résultats utiles plutôt qu’occultés pour gonfler le nombre de nœuds.
3.5 Conformité datée et ancienne référence du pilote Sony
Le parcours de référence Sony d’HSIMC constitue un cas historique de recherche, pas une preuve rétroactive de conformité au nouveau protocole. Chaque expérience doit garder sa date, son matériel, son transport, sa version logicielle, son périmètre de test et son reçu original. Si un prototype ancien utilisait une poignée de main MCP antérieure ou un adaptateur spécifique, cela doit être indiqué. La révision 2026-07-28 apporte des incompatibilités ; toute migration est un Work à tester, non une nouvelle étiquette historique [E5].
Un nouveau pilote documente la version déclarée ou négociée, l’identité authentifiée, un ensemble minimal d’outils, le consentement, l’action observée, le condensat des preuves, les échecs et l’acceptation indépendante. Seules les configurations réellement testées peuvent être dites « MCP-ready ». L’objectif est une coopération fondée sur un contrat vérifiable, non la promesse de compatibilité universelle.
WORK / DECISION TESTSur une configuration expressément autorisée, démontrer séparément l’échange MCP à une version nommée, la préparation sûre du dispositif physique et un Work revu par une seconde personne. Une réussite partielle ne vaut pas déploiement de production.
PUBLIC EVIDENCE · SOURCE LINKS STATUS / BOUNDARY. Les affirmations protocolaires concernent MCP 2026-07-28 ; aucune conformité Sony ou autre équipement n’est présumée, ni aucun soutien de partenaire ou droit élargi.
NEXT GATE. Réutiliser les trois jalons aux chapitres 11, 16–18 et 30 ; établir un dossier Work propre au test avant toute exécution physique.
No third-party company endorsement or deployment authority. Technical sources and editorial status are dated. Reproduction without independent language review is experimental.