Les 3 & 4 juin derniers a eu lieu l’événement du Marcus Evans sur l’évolution de l’Architecte d’Entreprise. C’était l’occasion pour nous d’y animer la table ronde HIP. Elle a donné lieu à un échange passionnant entre Fabrice Legoeffic (Chief Architect Sephora) et Ibrahima Ndiaye (CTO La Fabrique Digitale RATP/Architecte d’entreprise) sur 4 enjeux clés :
📊 Maturité HIP : Deux approches, un même défi
Premier constat : chacune des deux organisations est consciente des enjeux liés à la nécessité d’adopter une stratégie d’intégration polyvalente et avance à son rythme selon ses contraintes, ses priorités projets et son niveau de maturité.
RATP : La transition est en cours du point-à-point vers l’API management, avec un fort enjeu de conduite du changement interne. L’intégration avec un écosystème partenaire est un moteur pour monter en maturité (standardisation et normalisation).
Sephora : À date, chaque zone géographique dispose de sa propre stratégie d’intégration, de ses socles. L’objectif moyen terme est de rationaliser, d’avoir une approche commune avec une convergence des socles (WebMethods, APIM, Kafka), avec une interrogation persistante sur le Target Operating Model (global vs région).
⚡ Temps réel : Pragmatisme avant tout
Le temps réel n’est plus un mythe technologique, mais reste un défi d’adoption métier.
RATP : certains systèmes offrent une réponse en quasi temps réel, mais l’information temps réel reste un défi. La RATP se focalise sur la valeur métier (flux voyageurs, maintenance) plutôt que sur la technologie
Sephora :une approche différenciée US / Europe. Les US sont très orientés temps réel vs APIs en Europe. Ici encore, il ne s’agit pas de faire du temps réel à tout prix, il est mis en œuvre sur les use cases qui s’y prêtent (click & collect, pilotage vente magasin) via une fondation Kafka. Il s’agit d’un gros changement de paradigme qui change les habitudes projets. Par ailleurs, l’intégration temps réel avec les SaaS (…) n’est pas simple, elle dépend fortement de leurs demies interfaces techniques disponibles.
🔒 Sécurité : Architecture défensive
La sécurité by design devient incontournable dans les stratégies d’intégration modernes.
RATP : Une segmentation stricte pour les infrastructures critiques (SI industriel vs SI Digitale vs SI de gestion), un équilibre entre interopérabilité et sécurité.
Sephora : Sécurité by design, la Sécurité est impliquée le plus en amont possible des projets. Garantir l’isolation multi-marques et la gestion stricte des données personnelles est une obligation stricte. Le middleware d’intégration, notamment l’API Gateway joue un rôle clé dans la sécurisation de l’exposition de nos services.
🎯 Résilience : Flexibilité et pragmatisme
L’avenir appartient aux architectures qui savent s’adapter sans tout révolutionner.
Consensus : L’IA ne remplacera pas les mécanismes d’intégration à court terme
Clé du succès : Best of Breed équilibré, éviter l’ultra-centralisation, conserver les connecteurs natifs quand pertinents
Insight majeur : La réussite d’une stratégie HIP repose autant sur l’accompagnement du changement que sur les choix technologiques !
Transformation de l’Architecture d’Entreprise 2025 : De la Gouvernance à l’Influence
Transformation de l'Architecture d'Entreprise 2025 : De la Gouvernance à l'Influence
Synthèse approfondie de l’événement Marcus Evans du 4 juin 2025
🎯 Introduction : Une Révolution Paradigmatique
L’événement Marcus Evans des 3-4 juin 2025 a marqué un tournant décisif dans l’évolution de l’architecture d’entreprise française. Avec des interventions des architectes de grandes entreprises françaises, l’événement a révélé une transformation fondamentale : le passage d’une approche traditionnelle de gouvernance vers un modèle d’influence proactive.
🌟 La Révolution de l’Influence selon un leader du transport public
Le CTO , a présenté la keynote révolutionnaire sur la maximisation de la valeur stratégique . Son message central bouleverse les pratiques établies :
« L’architecture d’entreprise n’est plus seulement une question de cadre, c’est une question d’impact »
Les 4 Piliers de la Transformation
Mission & Batailles : Définir la véritable mission de l’architecte d’entreprise
Gouvernance → Influence : Passer d’une approche traditionnelle à une approche plus dynamique
Outils d’Action : Comment passer à l’action avec des outils et déclencheurs concrets
Call to Action : Favoriser l’adhésion plutôt que le contrôle
L’architecte moderne ne cherche plus à tout contrôler mais à influencer intelligemment : « Nous n’avons pas besoin de tout contrôler, nous devons influencer les bonnes choses et les bonnes personnes ».
Cette approche repositionne l’architecte comme un catalyseur de transformation plutôt qu’un gardien de processus.
L’Évolution du Rôle de l’Architecte
🌐 Le cas d’un leader mondial de la cosmétique : Maîtriser la Convergence Globale-Locale
L’Approche Matricielle d’un Architecte a présenté une case study remarquable sur l’organisation de l’architecture d’entreprise .
Avec 3 000+ points de vente dans +30 marchés , cette entreprise illustre parfaitement les défis de convergence à l’échelle mondiale.
Niveau 2 – Principes Alignés : Principes communs, exécution autonome
l ✅ Cohérence stratégique
❌ Risque de divergence technique
Niveau 3 – Technologies Partagées : Technologies communes, opérations indépendantes
✅ Économies d’échelle, réduction OPEX
❌ Support business fort requis
Niveau 4 – Assets Réutilisés : Composants communs, adaptations locales
✅ Accélération déploiement
❌ Gouvernance robuste nécessaire
Niveau 5 – Instance Globale : Solution unique, efficacité standardisée
✅ OPEX minimal, convergence business
❌ CAPEX initial élevé
Vision Inspirante
Ce leader de cosmétique, s’inspire d’Antoine de Saint-Exupéry : « As for the future, your task is not to foresee it, but to enable it » , positionnant l’architecture comme un enabler du futur plutôt qu’un simple gestionnaire du présent.
Implication Précoce : Être impliqué dès le début du processus
Approche par les Risques : Travailler le besoin avant la solution technique, avec une approche par les risques après les enjeux business
Amélioration Continue : S’appuyer sur les assets transverses et améliorer le socle en continu
🌱 Développement Durable : La Nouvelle Priorité Stratégique
Impact Environnemental du Numérique
La table ronde du 4 juin , modérée par Philippe Bucco (Club Urba-EA) , a positionné le développement durable comme priorité stratégique .
Chiffres Clés Révélateurs
Équipements Utilisateurs : 72% des impacts de réchauffement climatique , avec des impacts majoritairement répartis entre fabrication et utilisation
Centres de Données : 46% de l’empreinte carbone du numérique , représentant 11% de l’électricité française (51,5 TWh)
Réseaux : La phase d’utilisation concentre les impacts
Gouvernance Éco-Responsable
Besoin urgent d’une gouvernance pour prioriser les projets à impact environnemental minimisé et écarter ceux jugés « déficitaires ».
Impact IA non comptabilisé : Les impacts de l’arrivée de l’IA ne sont pas encore comptabilisés , nécessitant une anticipation stratégique.
🚀 Excellence Opérationnelle
Transformation vers un Modèle Éditeur
Le Directeur Architecture d’Entreprise de ce leader du transport voyageurs, a présenté la réussite de son organisation dans sa transformation vers un modèle éditeur Loading…
Le Visual Programming part à la conquête des DSI
Le Visual Programming part à la conquête des DSI
22 octobre 2024
Architecture
Clément Lefranc
Senior Manager Architecture
Le NoCode Summit 2024 en a été la vitrine et s’est révélé fort intéressant par bien des aspects :
être dans l’ambiance, l’effervescence de cet écosystème qui innove très vite,
percevoir les solutions qui reviennent souvent dans les témoignages, identifier clairement les start-up, et les scale-up,
bénéficier de retours avisés de petits / grands comptes ayant d’ores et déjà adopté ces stacks en Production.
Si vous parlez de NoCode/LowCode…un vaccin des dernières tendances vous sera bénéfique.
NoCode, démarrant par une négation, n’est pas vendeur, braque les développeurs avec pour conséquence un frein à l’adoption de ces technologies…Alors même que le “NoCode” requiert des compétences fondamentales telles que la logique et l’algorithmie. Le “LowCode” quant à lui requiert parfois de coder concrètement pour couvrir le cas d’application souhaité.
Désormais, il conviendra de parler de :
Keyboard Programming – Développement traditionnel dans le langage qui vous plaira,
Visual Programming (ex NoCode / Low Code),
GenAI Programming.
Il s’agissait ici de la troisième édition du Summit, et une belle montée en maturité (Prod ready) des acteurs a été constatée, ne serait-ce que de part leur adoption par des Grands Comptes (ex : BRED, System U, BNPP, Docaposte, CDC, Europ Assistance, LCL, L’Oréal, BPI France) qui témoignent de retours d’expériences très positifs.
Vous constaterez sur les affichages de sponsoring du foisonnement de solutions. Nous assisterons avec quasi certitude à une consolidation de marché dans les années à venir car plusieurs solutions se concurrencent sur les mêmes positionnements, avec bien évidemment des particularités.
Voici un aperçu des différents positionnements constatés :
Solution de BDD avec UI/UX on top : AirTable, baserow
Solution de tests fonctionnels, techniques : MrSuricate
Solution pour développer des outils de productivité en interne (mini JIRA, mini CRM, …) : TimeTonic, DAMAaaS
Solution de monitoring : ncScale
…
Source : Kevin Ku – Pexels
Le choix de l’une ou l’autre des solutions doit se faire de façon éclairée avec une liste de critères / contraintes bien établie, dont voici un petit extrait :
Quels sont mes uses cases ?
Est-ce pour un usage interne ou pour du Customer Facing ?
Quels vont être les utilisateurs (IT ? Business ? Les deux ?) ?
Solution OpenSource ou propriétaire ?
Solution Française only ?
Hosting OnPrem ou Cloud ?
Respect des normes réglementaires ? sécurité ?
Quelle est la maturité et la pérennité de l’éditeur / la solution ?
Quelles sont les capacités de réversibilité ?
Quel est le niveau de couverture technico-fonctionnelle ?
Quel est l’effort pour se Up-Skill et l’utiliser ?
et sans oublier toutes les autres considérations: scalabilité, modèle financier, …
Des stacks commencent d’ores et déjà à se démarquer via les témoignages :
WeWeb en Front, cocorico, solution Française, génère du VueJS exportable,
Xano en Back-end truste le marché, le plus complet, le plus scalable, le plus sécurisé,
Make en orchestration API.
Se lancer dans l’aventure Visual Programming, c’est être conscient des problèmes que vous rencontrez et des bénéfices qu’ils peuvent vous apporter :
Réconcilier le Business et l’IT (Dev): enfin ils peuvent se comprendre de part l’aspect visuel et instantané du développement,
Être en Agilité par défaut,
Accélérer la phase de Build, tout en conservant ou en augmentant la qualité…
… et par conséquent améliorer le TimeToProd,
… et par conséquent diminuer les coûts projets,
Désengorger l’IT en décentralisant (gouvernance requise) certains projets dans les BU,
Redonner une bouffée d’oxygène au BUILD, qui se voit souvent écraser par le poids du RUN et de la gestion de l’obsolescence.
Le NoCode ne rime pas avec NoMethodology. Qu’il s’agisse d’une démarche tactique ou stratégique, il y a des clés de succès :
Associer les différents futurs profils utilisateurs au choix de la stack Visual Programming,
Les phases d’expression de besoin / cadrage / conception d’un projet en Visual Programming ne changent pas et une grande importance doit leur être accordée,
Une Gouvernance doit être définie en cohérence avec votre organisation (NoCode office centralisé? des référents dans les BU?),
Le Visual Programming ne permet pas de tout faire. Un cadre, un arbre d’éligibilité, des bonnes pratiques doivent être établis pour les utiliser à bon escient,
Think BIG, Act SMALL : démarrer petit, sur un scope favorable mais avec des points de douleurs identifiés et revendiqués. Démontrer le succès sur un premier scope attire les autres use cases et la quasi généralisation sur les périmètres éligibles,
Appliquer les mêmes bonnes pratiques que sur un projet de développement classique.
Toute rupture technologique, tout nouvel écosystème apporte avec lui son lot de freins et de réticences:
L’écosystème est assez jeune et la pérennité des solutions pose légitimement question,
Quid du fameux Vendor Lock-in et de la capacité de réversibilité. Pour les mitiger il faut être très mature et Responsable sur la phase de cadrage, conception, documentation de ce qui sera développé.
Le NoCode sacrifie-t-il la Sécurité ? Il faut s’assurer que la Sécurité n’est pas mise de côté et que la plateforme dispose des bonnes certifications (SOC2, ISO 27001, Hipaa, …) ainsi que des mécanismes maintenant bien connue sur la GRC (Governance, Risk, Compliance) de part le contrôle des accès, les permissions fines, les audits logs, la détection des incidents, …
Comment faire pour tester du NoCode quand les plateformes ne proposent pas intrinsèquement ces fonctionnalités ?
Les plateformes disposent-elles de mécanismes pour prévenir et éviter un Burn de facturation sur ce modèle très “as-a-service” ?
Actuellement, moins d’un pourcent de la population mondiale sait programmer. La démocratisation et l’accessibilité introduite par le Visual Programming a le bénéfice d’ouvrir la voie à toute une Diversité de personnes en quête de reconversion.
Mais … comme le souligne très justement Jean-Marc Jancovici également le net inconvénient et le risque majeur d’accentuer significativement une prolifération applicative avec des services digitaux futiles et inutiles. Sur notre planète à ressource finie, le numérique représente 4% des gaz à effet de serre (GES), cette débauche de moyens (énergétiques et intellectuels) sur ces sujets ne fait qu’accroître exponentiellement les usages digitaux… et leurs impacts.
Derrière mon clavier, je visual programme avec modération et sobriété. La consommation digitale excessive est dangereuse pour la planète, ceci est un message de Rhapsodies Conseil.
Impulsées par l’avènement du Cloud et du DevOps, les mouvances “as Code” et “Software Defined X” ont grandement amélioré la gestion du cycle de vie des assets informatiques (infrastructure, middleware, serveur d’application, …) avec principalement :
L’Infrastructure as Code (IaC),
La Configuration as Code,
Nous détaillerons dans un futur article le positionnement de chacun et les grands paradigmes en présence (procédurale vs déclaratif), qui reposent sur une caractéristique commune: l’utilisation de template/playbook au format normalisé (HCL, YAML, …) décrivant l’état final à atteindre ou le moyen d’y aller.
Même si la syntaxe est Human Readable, il peut être fastidieux à l’échelle d’un SI enperpétuelle évolution d’écrire et de mettre à jour ces fichiers de description.
Bien qu’il existe de plus en plus de plateformes simplifiant la création de ceux-ci sur base de conception visuelle en LowCode/NoCode ou de schématisation…Que diriez-vous de troquer d’un point de vue utilisateur le ”as Code” par du ‘as Prompt” ?
#GenAI à la rescousse
Le terrain de jeux des Large Language Models (LLM) et de la GenAI ne cesse de croître, en n’oubliant pas au passage l’ingénierie logicielle.
Imaginez pouvoir simplement demander “Provisionne un cluster de VM EC2 avec NGINX en exposition publique ainsi qu’une base Elasticache” pour voir votre souhait exaucé instantanément.
D’ailleurs, n’imaginez plus, car l’Infrastructure as Prompt (IaP) est déjà proposée par Pulumi AI, et bien d’autres en cours (depX) ou à venir.
Ce positionnement et les avancées rapides et significatives dans ce domaine ne sont pas étonnantes car nous sommes en plein dans le domaine de prédilection des LLMs: les langages.
Qu’ils s’agissent de langages parlés (Français, Anglais, …), de langages de programmation (Python, JavaScript, Rust), de langage de description (HCL, YAML, …), ils ont tous deux concepts fondamentaux:
Un dictionnaire, un vocabulaire, une liste de mots avec une (plusieurs) signification(s) connue(s),
Une grammaire et des règles syntaxiques plus ou moins strictes donnant un sens particulier à la suite de mots d’une phrase ou d’une ligne de fichier de configuration.
Plus le dictionnaire et la grammaire d’un langage sont dépourvus d’ambiguïtés, plus le degré de maturité et la mise en application de la GenAI et des LLMs sur celui-ci peut-être rapide.
L’Infrastructure as Prompt n’est pas une rupture totale avec le “as Code”, simplement une modernisation de l’interface “Homme-Clavier”.
En effet, peu importe le moyen (création manuelle, auto-génération via prompt) l’aboutissement de cette première étape est la disponibilité du fichier de description.
Le cœur du réacteur, à savoir la traduction du <fichier de conf> en actions pour <provisionner et configurer les ressources>, est toujours nécessaire.
A l’avenir elle pourra se révéler un parfait assistant pour faire des recommandations et propositions d’ajustement vis-a-vis de la demande initiale pour optimiser l’architecture à déployer:
Prioriser les services managés,
Prioriser le serverless,
Etre compliant avec les best practices des frameworks d’architecture des Clouders (AWS Well Architected Framework, …),
Security By Design,
RIght sizing de l’infrastructure,
Opter pour des ressources ayant une empreinte carbone et environnementale optimisées.
#La confiance n’exclut pas le contrôle
Bien que la baguette magique qu’apporte cette surcouche soit alléchante, nous ne pouvons qu’abonder les paroles de Benjamin Bayard dans son interview Thinkerview Intelligence artificielle, bullsh*t, pipotron ? (25min) : “tous les systèmes de production de contenus si ce n’est pas à destination d’un spécialiste du domaine qui va relire le truc, c’est dangereux.” Dans un avenir proche l’Infrastructure as Prompt // la Configuration as Prompt n’est pas à mettre dans les mains de Madame Michu (que nous respectons par ailleurs) qui ne saura pas vérifier et corriger le contenu de Provisioning, de Configuration ou de Change qui a été automatiquement généré. Nous vous laissons imaginer les effets de bords potentiels en cas de mauvaise configuration (impact production, impact financier, …) dont le responsable ne serait autre que la Personne ayant validé le déploiement. Impossible de se dédouaner avec un sinistre “c’est de la faute du as Prompt”.
Vous l’avez compris, la déferlante LLM et GenAI continue de gagner du terrain dans l’IT, le potentiel est énorme mais ne remplace en rien la nécessité d’avoir des experts du domaine. Le “as Prompt” se révèle être un énorme accélérateur pour l’apprentissage du sujet, ou dans le quotidien de l’expert .. qui devra avoir une recrudescence de prudence quant aux configurations qui ont été automatiquement générées.
La blockchain et l’IoT sont deux technologies à la pointe de l’innovation, sont-elles pour autant interopérables ? Quels bénéfices peut apporter l’utilisation de la blockchain sur des uses cases IoT ?
Dans cet article, nous vous proposons tout d’abord d’analyser les caractéristiques propres de ces technologies et d’éclairer certains mythes et incompréhensions sur la faisabilité d’un tel mariage, qui n’est pas forcément immédiat pour tout le monde.
Puis, nous vous présenterons les points de convergence et les avantages attendus d’une utilisation conjointe IoT & Blockchain.
Zoom sur la blockchain
La blockchain peut être assimilée à une base de données, ou plus précisément à un grand registre distribué sur le réseau. Son intégrité est garantie par des mécanismes de consensus et de cryptographie, sans avoir besoin d’un organisme central ou d’intermédiaires. Comme pour un grand livre, rien n’est effaçable ou modifiable rétroactivement sur la Blockchain. Pour changer l’information nous avons uniquement la possibilité d’en ajouter une autre.
Zoom sur l’IoT
Bien plus concret et lié à la vie de tous les jours, la déferlante d’objets connectés, constituant en partie l’IoT, est en forte croissance.
Les montres connectées, les tags RFID, les capteurs de tous types, etc. sont de plus en plus présents dans notre quotidien. Ils demandent une attention particulière et nécessitent des architectures performantes, respectueuses de la vie privée et sécurisées. La sécurité étant justement, un point de vigilance majeur de cette technologie.
Blockchain & IoT : deux sujets à priori orthogonaux ?
De prime abord, nous pourrions penser que l’association de ces deux technologies est peu réaliste de part leurs différences fondamentales :
Le développement de l’Edge Computing sur les uses cases IoT tend à relocaliser les traitements au plus près du terrain et donc des objets.
Cette opportunité serait-elle la clef pour marier les deux technologies ?
Analyse des positionnements de la blockchain et l’IoT
Un des objectifs des objets connectés est de collecter des données variées du terrain afin d’en créer une vision consolidée et cohérente. Le besoin de traiter les données de façon décentralisée est motivé par un niveau de performance accru dans la prise de décision en temps réel (pré-traitement des données en local…), la garantie de traçabilité des sources de données.
Une distinction claire des rôles émerge :
L’IoT se positionne sur la couche matériel (pour capter l’information) et la couche applicative (pour traiter l’information),
La Blockchain se positionne plus au niveau du protocole de transmission et de la sécurisation de l’information.
Les rôles deviennent ainsi plus clairs :
Les objets connectés, positionnés au niveau application, deviennent ici les responsables de la création des transactions sur la Blockchain. Par des mécanismes de cryptographie, chaque objet détient une clé privée, avec laquelle il signe les transactions.
La Blockchain détient l’objectif de valider la transaction, de l’inscrire dans la chaîne liée à l’objet et de garantir la propriété de l’information, liée à la propriété de l’objet connecté
En plus de garantir la véracité de l‘information, cette architecture vise à appuyer un principe fondamental de la Blockchain : le respect de la vie privée. Celui-ci est garanti par le lien entre la personne et son objet connecté.
En effet, grâce à la cryptographie, seule la personne physique décide quelles informations rendre publiques et éventuellement les conditions d’exposition (monétisation…).
L’intégration de la Blockchain et de l’IoT prend ainsi tout son sens, en proposant des rôles complémentaires.
L’objectif étant de pallier au “manque de sécurité” souvent reproché à l’IoT en créant un réseau sécurisé garantissant la vie privée des personnes.
Et si toutes les données collectées par nos systèmes IoT (Nest, Alexa, etc.) n’étaient utilisables que par nous, selon nos restrictions et en assurant le respect de notre vie privée ?
Les cas d’usage émergent et le potentiel est immense
L’accostage de la Blockchain et de l’IoT n’est pas réellement un nouveau sujet. Les principes que nous avons cités auparavant ont déjà été analysés et des premières mises en application existent déjà sur les différentes typologies de transaction :
Human to machine,
Machine to machine,
Machine to human.
Les cas d’usage sont presque illimités, la Blockchain se positionnant au niveau du protocole, la mise en application dépend essentiellement de la créativité des personnes.
Cas d’usage possible #1 : la traçabilité de la filière alimentaire (du producteur au commerçant)
La problématique du tracking de la filière alimentaire est principalement liée au problème de contrefaçons qui surviennent à cause de la complexité des supply chains. La solution repose sur l’utilisation de tags liés à une Blockchain. Le scan d’un tag déclenche la création d’un block.
La Blockchain n’étant pas corruptible (dans les faits c’est plus subtile, nous ne souhaitons pas ouvrir ce débat ici 🙂 ), elle permettrait de reconstruire toute l’histoire d’un produit en garantissant la véracité du tracking.
Cas d’usage possible #2 : la voiture autonome sur autoroute
L’autonomie des véhicules est un sujet en vogue, certaines voitures peuvent déjà rouler sur autoroute sans intervention du conducteur (cf. classification des véhicules autonomes).
Et si notre véhicule autonome pouvait payer le péage automatiquement ? sans avoir à utiliser le réseau télépéage ni passer par un autre intermédiaire, voir même se recharger en réalisant une transaction avec une autre voiture électrique pour s’échanger de l’énergie sans intervention humaine et en toute sécurité ?
Technologiquement, ces deux cas d’usage sont déjà possibles et réalisables, par les mécanismes de sécurité et de validation des transactions de la Blockchain.
Le marché commence à investir dans la blockchain et l’IoT
Depuis plusieurs années maintenant, des Startups investissent ce segment pour inventer de nouvelles architectures et de nouveaux usages.
Voici quelques exemples :
IOTA
IOTA est une crypto monnaie destinée à couvrir les cas d’usages de micropaiement entre Objets Connectés. Elle repose sur une “Blockchain” remaniée, nommée Tangle, corrigeant certains facteurs limitant (forte consommation d’énergie, beaucoup de ressources nécessaires, …) afin d’être utilisée par une flotte d’objets connectés.
SLOCK.IT
Slock.it est un SDK (Software Development Kit) offrant une palette d’outils permettant de connecter des objets à la Blockchain Ethereum.
Les premiers usages IoT adressés ici concernent la consommation de services de la vie quotidienne. Par exemple, réserver et payer sa location directement devant la porte via un périphérique IoT et un règlement Ethereum, sans besoin d’intermédiaires (ex. AirBnB), ou encore réserver une voiture sans passer par Getaround (Drivy). Dans un objectif de supprimer les intermédiaires et sécuriser les paiements, les possibilités d’associations sont multiples et prometteuses.
SWEATCOIN
Sweatcoin est une mise en application, disponible aux clients finaux, qui permet de gagner des sweatcoins en marchant, par le biais de son téléphone portable. Bien que cela ne soit pas encore identifiable en tant que cryptomonnaie, car pas encore sur technologie Blockchain, l’objectif de l’entreprise est bien de migrer vers cette technologie.
En conclusion
Les promesses sont nombreuses et permettent d’entrevoir des solutions concrètes pour sécuriser le traitement des données IoT. Les premières mises en application sur le sujet, l’investissement du marché et les prises de positions dans les deux camps nous confortent dans cette vision.
Cependant, ne perdons pas de vue que de nombreux points doivent encore être abordés pour affiner les liens entre Blockchain et IoT.
Est-ce la lumière au bout du tunnel et un accélérateur complémentaire au déploiement massif de l’IoT chez les particuliers ? L’avenir nous le dira mais tous les feux semblent au vert.
Et vous, encore frileux pour les contraintes liées à la protection de vos données, qu’en pensez-vous ? Serait-ce ici un premier pas pour vous convaincre ?
Capteur de température intelligent , smart watch, smart light … les smart things c’est IN, c’est HYPE, la majorité des publications en font l’éloge.
Est-ce que ces objets sont si smart qu’ils le prétendent ? Uniquement du point de vue technologique ? Qu’en est-il du point de vue utilisateur ?
Prenons le cas de Mr Dupont qui acquiert il y a quelques années son premier Smart Bracelet : le Jawbone UP 3.
Sur le papier : cet objet est vendu comme très intelligent car disposant de plein de capteurs (accéléromètre, gyroscope, température, …).
Dans la vraie vie :
Mr Dupont est agacé car certaines fonctionnalités n’ont jamais été implémentées bien que les capteurs nécessaires soient présents,
Étant très fragile, le bracelet (caoutchouc) s’est rompu à de multiple reprises. Par ailleurs, cette partie disposant d’un certain nombre de capteurs et étant indissociable de la véritable partie électronique, Mr Dupont a dû faire remplacer la totalité de son objet bon nombres de fois.
La société Jawbone a arrêté son activité Wearable grand public, les serveurs ont été débranchés.
Bilan :
L’objet en lui même fonctionne bien, mais ne dispose pas d’écran pour afficher les données basiques (nombres de pas, …),
La synchronisation des données entre l’objet et le smartphone n’est plus fonctionnelle,
Quoi qu’il arrive le service étant décommissionné chez le fournisseur, les indicateurs et recommandations pour l’utilisateur ne sont plus calculés,
Les centaines de millions d’unités vendues peuvent être jetées à la poubelle.
Ce simple exemple peut être décliné sur un grand catalogue de produit « smart ».
En conclusion
Il est effectivement facile d’écrire Smart sur un package marketing mais ce n’est pas une mince affaire à implémenter.
L’intelligence de l’objet doit être pensée sur chacune des phases du projet : de la conception de l’objet, en passant par l’architecture IoT (la localisation des traitements, …), jusqu’à l’ouverture à d’autres écosystèmes.
Nous tenterons très prochainement via un nouvel article (#RhapsodiesConseil #TeamIoT) de vous éclairer sur les différentes stratégies concernant la localisation des traitements (Cloud Computing VS Edge Computing).
