Mettre en place la fonction Urbanisme/Architecture dans une Entreprise n’est jamais simple. Faut-il vraiment suivre le déroulement de méthodologies lourdes et complexes, style TOGAF ? Nous proposons une approche plus rapide et plus économique : partir d’outils déjà éprouvés, et en contrepartie, concentrer l’effort sur l’accompagnement au changement.
Démarrer une pratique d’architecture n’a rien d’une sinécure. Par où commencer ? Où dégager très vite de la valeur ajoutée ? Faut-il vraiment se lancer dans le déroulement d’une démarche méthodologique complète, mais longue et coûteuse? Notre proposition est de commencer par s’équiper d’une boîte à outils. En effet, au quotidien, l’architecte a besoin d’un petit nombre d’outils. Oui, mais lesquels ?
La contribution positive de l’architecte se démontre sur le terrain, dans sa capacité à accompagner les équipes de projet pour éclairer la voie et trouver les meilleures solutions, à la fois sur le court et sur le long terme. Pour cela, il a besoin des outils suivants:
un corpus de règles d’architecture,
un modèle fonctionnel de référence, base d’une cible d’urbanisation du système d’information,
un catalogue de normes et standards (modèles « design patterns », matériels, logiciels,…)
Sans oublier :
des cartographies qui décrivent les systèmes de l’entreprise : processus, applications,…
une procédure d’instruction de projet bien établie, avec des acteurs et des rôles bien identifiés,
un modèle de document qui décrit la ou les solutions envisagées pour le projet, et en synthétise les points-clé (objectifs, solution proposée, risques, etc…), permettant ainsi à toutes les parties prenantes de s’approprier rapidement le sujet, et de prendre une décision en toute connaissance de cause.
Passer du sur-mesure au prêt-à-porter… et vice-versa !
Comment fabriquer ces outils ? Bien sûr, on pourrait dérouler une démarche complète de développement de l’architecture, mais il est plus rapide de partir d’un corpus de bonnes pratiques déjà éprouvées, que l’on enrichira pour l’adapter aux spécificités de l’entreprise. En particulier, on constate que d’une entreprise à l’autre, une partie des règles d’architecture sont communes. Cela se comprend : il en est de même dans toutes les disciplines de construction, qu’il s’agisse de fabriquer des bâtiments (par exemple, les règles de calcul de la section d’un pilier en béton), des meubles, ou des véhicules.
Il en va de même pour le processus d’instruction des projets : les étapes à respecter, les rôles et les responsabilités des différentes parties prenantes sont identiques. Seules les procédures sont dépendantes de l’organisation, sa taille, et ses enjeux.
Des modèles de solutions et des standards de facto sont également disponibles : architectures n-tiers, décisionnelles, modèles IAM pour la gestion de la sécurité des accès, Hadoop pour le big data…
Le modèle fonctionnel est spécifique pour ce qui concerne les fonctions propres au(x) métier(s) de l’Entreprise : les fonctions génériques (RH, Finance, Compta, GED,…) étant de leur côté identiques d’une Entreprise à l’autre. Deux entreprises qui font le même métier ont des cadres fonctionnels extrêmement ressemblants !
Une logique du « juste assez »
Il existe de nombreuses méthodes pour mettre en place l’architecture d’entreprise, et il existe aussi de nombreuses solutions pour outiller ce métier. Ces méthodes ont pour but de guider les architectes pour la production et le maintien de ce que l’on appelle parfois des «actifs» d’architecture.
Ces méthodes, telles que TOGAF, sont parfois jugées longues et coûteuses à mettre en place, et ce, à juste titre. En effet, elles constituent une « check-list » certes très utile, mais elles se concentrent sur la fabrication de ces outils, et non sur leur utilisation au quotidien. A notre sens, du fait de leur complexité, elles sont à utiliser dans des conditions bien particulières, pour des programmes de transformation significatifs. Or, il est très rare que le système d’information d’une entreprise soit reconstruit de fond en comble.
A l’inverse, notre approche consiste à partir d’outils déjà utilisables, et de les adapter aux spécificités de l’entreprise. Cette approche est donc beaucoup plus rapide et économique : typiquement, quelques semaines suffisent pour démarrer une fonction Architecture.
Le véritable enjeu : accompagner le changement
Les entreprises sont de plus en plus nombreuses à avoir compris l’intérêt de la fonction architecture. Toutefois, la déployer reste un travail délicat : au départ, elle est souvent perçue comme superflue ou intrusive… Nos interventions chez nos clients se focalisent sur l’enjeu principal : accompagner ce changement, et faire en sorte qu’il soit accepté.
Soyons réalistes : on ne forme pas un architecte en six mois, ni même en trois ans, quelle que soit la méthode utilisée. En revanche, en quelques semaines, il est possible de l’aider à s’approprier des outils, et à les adapter aux enjeux de son entreprise et à son niveau de maturité.
Pour réussir ce changement, il est important d’accompagner l’architecte sur deux ou trois projets, afin de l’aider à prendre en main ses outils sur des cas concrets. Rien de tel en effet que l’application concrète à des projets de terrain, quelle que soit leur taille, pour démontrer le bien-fondé et la valeur ajoutée de l’architecture.
Et si l’architecture d’entreprise était plus présente dans notre vie quotidienne que nous ne le pensions ? Nous vous assurons qu’il est possible de discuter des différentes approches possibles dans l’accompagnement au développement de la solution des projets en faisant un parallèle avec l’éducation des enfants, de façon simple et basique (coucou Orelsan). Loin de nous l’idée d’infantiliser les projets, nous parlons ici de la solution / le résultat. Les projets partent d’une idée, d’une conception et vont jusqu’à l’émancipation. D’ailleurs ne dit-on pas que « l’on a accouché » d’un projet (ou qu’il accouche d’une souris) ?
Et il se trouve que nous avons tous été enfant. Certains ont même pris le risque d’en avoir à leur tour. Alors nous espérons que tous pourront se reconnaitre dans nos paroles.
Mais qui est ce « Nous » ?
Chloé, architecte d’entreprise, interne d’une grande société qui se demande si son travail est un bullshit job (merci David Graeber). Elle est également jeune maman.
Olivier, architecte d’entreprise senior, consultant et ami de Chloé. Papa (divorcé/recomposé) de grands enfants.
Note : toute ressemblance avec des projets ou des enfants existants ne serait bien entendu que fortuit.
Note 2 : vous allez sûrement vous retrouver dans les lignes ci-dessous. N’hésitez pas à réagir et à nous faire parvenir vos commentaires, autant sur la forme que le fond, que nous fassions tourner la roue de l’amélioration continue ! Allez, fin du suspense, c’est parti.
De l’importance du cadre. La relation avec ses enfants.
Cadre ou pas cadre ?
Chloé : Je lis en ce moment un livre passionnant sur la parentalité positive. Je t’explique.
Dans le monde de la parentalité, les spécialistes ont pris position : aussi contradictoire que cela puisse paraitre, pour qu’un enfant grandisse libre, les parents se doivent de poser un cadre aux enfants et leur apprendre à le respecter. Le Larousse dit qu’un cadre est « Ce qui borne, limite l’action de quelqu’un, de quelque chose ».
En pratique, nous avons plusieurs tendances :
Afin de respecter la liberté de l’enfant, il existe des parents qui écoutent les envies de l’enfant et n’y oppose aucun cadre.
Pour certains, c’est évident, l’enfant a besoin de cadre. Celui-ci existe dans leur esprit avant même l’arrivée de l’enfant. Il est construit sur les principes et valeurs animant la vie de l’adulte. Parfois, il est hérité de leur propre éducation.
Enfin, pour d’autres, un parent doit apprendre en marchant avec son enfant : ce cadre se construit au fur et à mesure du développement de l’enfant.
La bonne manière de faire est celle qui permet l’épanouissement de chacun ! Est-ce que cette façon de voir est valable pour l’informatique ?
« Les parents sont le cadre, et l’enfant la peinture. »
François de Singly
Un cadre…
Olivier : C’est un très bon parallèle. Mais il n’existe pas de cadre universel, n’est-ce pas ?
Que se passe-t-il quand le cadre est très, voire trop strict ? Tu vas subir bientôt la première étape de rébellion : la période du « NON ! » vers les 2 ans de l’enfant, suivi ensuite de l’adolescence, puis cette remise en cause vers 40 ans (davantage 30 ans de nos jours). Ce sont des périodes sensibles où un cadre reste essentiel mais devient un grand point de friction.
Dans l’entreprise, un exemple très actuel de situation qui bouscule nos convictions est l’apparition des projets dits « en mode Agile ». L’ancien système étant par trop contraignant, une nouvelle façon de faire est apparue, perturbant tout l’écosystème classique : les processus, les acteurs, les principes…
Les solutions des projets qui suivaient les règles établies faisaient la fierté de leurs géniteurs car ils étaient dans le cadre et avaient « les bons tampons sur le papier » (indépendamment des résultats produits…). Depuis, les projets se sont réinventés, avec ou sans autorisation. Alors devons-nous supprimer le cadre car la rigidité empêche le Système d’Information d’évoluer ? Est-ce qu’on dit qu’un cadre empêche un enfant d’évoluer ? Tout va dépendre du cadre et comment on choisit de l’utiliser. Un cadre peut aussi être très macro et simple : du bon sens en somme !
… des principes, des règles et des dérogations
Olivier : Le cadre se décline en plusieurs étapes / niveaux et doit pouvoir s’adapter.
De manière générale, un cadre s’accompagne de principes (je veux un enfant poli, je veux un SI sécurisé) et de règles (« dis bonjour à la dame », « montre patte blanche au comité sécurité »). Une fois les règles définies, cela permet de tracer le suivi ou non des règles, via un protocole de dérogation (mon enfant n’a pas dit bonjour aujourd’hui à la dame, il était fatigué, mais demain promis, il le dira // le projet n’a pas appliqué cette règle d’urbanisme par manque de budget / temps mais promis il le fera l’an prochain). La dérogation est par définition temporaire. Attention aux abus donc ! Si l’enfant ne dit jamais bonjour parce qu’il est toujours fatigué, soit le principe n’est pas bon, soit l’enfant a un vrai souci de santé. En parlant de cela, comment se porte ton SI ?!
Ne me promets pas la lune ni les étoiles, promets moi d’être à mes côtés pour les admirer
Pas de règles ?
Chloé : aussi bien qu’un autre, j’imagine… Peut-on se contenter du niveau 1, de n’avoir que des principes ?
Il est possible d’élever un enfant sans règles, avec uniquement des principes. « Je comprends que mettre un casque t’embête, mais pour ta sécurité, tu te dois de protéger la tête. » et à l’enfant de trouver par ses propres moyens, une solution pour respecter le principe et rester dans le cadre. Il est évident qu’à 10 ans, l’enfant appréciera cette confiance accordée. Il est tout aussi évident qu’à 3 ans, l’enfant est trop immature pour saisir un tel discours. C’est une solution qui ne fonctionne qu’avec des acteurs matures et conscients des tenants et aboutissants. Si nous revenons à notre IT, cela signifie qu’il est possible de présenter des règles à tous, et seulement des principes aux acteurs qui sont sensibilisés à l’architecture et sauront d’eux-mêmes prendre les bonnes décisions car conscients des impacts et risques.
« Ne me promets pas la lune ni les étoiles. Promets-moi d’être à mes côtés pour les admirer. »
Ni cadre ni principe
Olivier : Je dirai même plus, et sans les principes il reste quoi ?
Lors de la naissance d’une entreprise, seules les valeurs sont présentes : nous œuvrons au bien-être de la planète, des animaux, des sportifs, … Il n’y a ni cadre, ni principe. Si cette entreprise a la chance de réussir et de grandir, alors les cadres et principes vont naturellement apparaitre, sinon l’entreprise deviendra ingérable. Lorsqu’on étudie les licornes, ces start-ups qui transforment l’essai, et qui grossissent rapidement, nous constatons qu’elles dérivent lorsqu’elles persistent à fonctionner « comme avant ».
Le bonheur est dans la diversité
Chloé : nous sommes fruits de la diversité et du hasard !
Le résultat de notre projet (informatique) est comme un enfant, personne ne sait, dès le départ, ce qu’il va devenir. Sera-t-il comme nous l’avions imaginé ? Va-t-il se rebeller ? Par quelles phases va-t-il passer ? Comment allons-nous gérer les crises qui ne manqueront pas de survenir ? C’est tout ce qui fait le charme de l’éducation et des projets… Ne pas savoir et apprendre en marchant.
Conclusion
Olivier : si je résume : un cadre oui obligatoirement ; des principes, très certainement ; des règles, ça s’étudie. J’élève mon enfant afin qu’il soit sociable, il doit être poli, il dira bonjour. Plus il grandit, et plus mon discours se contentera de « tu ne vis pas tout seul ». Nous voyons mieux les enjeux avec cette métaphore !
Rappelons-nous que les cadres ne sont pas présents pour brider les projets. Au contraire, ils sont là pour les aider. Le cadre permet la naissance des principes, donnant à leur tour vie aux règles qui régissent le fonctionnement du SI et des acteurs de celui-ci. Au vu du nombre d’évolutions que connaît un SI d’entreprise, l’absence de cadre serait vraiment un frein.
Les règles permettent aux projets « routiniers » (qui sont en plus grande proportion) de suivre des voies « balisées ». Puis, en fonction des différentes phases et des différents types de projet, il est intéressant d’imposer des règles, ou pas, ou moins…
Même l’idéation est aidée par des principes, certes légers ! En revanche, il est important de garder en tête qu’un principe est « au service de ». S’il perd de son intérêt, c’est qu’il est temps de le faire évoluer.
Restez connectés pour les prochains chapitres de « Architecture d’entreprise et parentalité » :
Chapitre 2 : gérer les crises (rejet de l’autorité parentale, faire la police, rupture de la confiance)
Chapitre 3 : les autres membres de la famille (grands parents, frères et sœurs, amis/voisins proches)
Chapitre 4 : les grandes transformations (arrivée d’un nouvel enfant, divorce, famille recomposée)
Un programme de transformation a été engagé afin mettre en place une nouvelle Banque en ligne. Cette nouvelle banque doit mettre en place des pratiques d’Architecture d’Entreprise afin de maitriser la mise en place de son nouveau SI et de ses futures évolutions
Solution
Assister le nouveau responsable de l’Architecture d’Entreprise dans sa prise de fonction:
Cadrer la désimbrication des SI historiques avec les nouveaux SI
Mettre en place les processus de l’Architecture d’Entreprise
Définit le rôle vis-à-vis des projets
Mettre en place le Comité d’Architecture d’Entreprise
Définir la capitalisation /modélisation nécessaire du SI
Mettre en place les outils de modélisation et de gestion de la documentation (MEGA, PowerDesigner, Confluence)
Construire les vues d’ensemble nécessaire à la maitrise de la trajectoire de la transformation du SI (Plan d’occupation des sols, Vue d’ensemble du SI et paliers, liste des applications et flux etc.)
Construire la vue des données dans le SI (Objets Métiers, SID etc.)
Bénéfices
Mise en place du Comité d’Architecture d’Entreprise pour partager les trajectoires et les décisions
Mise en place de la capitalisation pour le partage de la connaissance au sein de la banque
Mise en place des outils de capitalisation et formation des futurs utilisateurs
Les autres success stories qui peuvent vous intéresser
Le client a initié une grande transformation métier sur 6 ans. Afin d’accompagner cette transformation à l’ère du Digital, un programme visant à mettre en œuvre une Hybrid Integration Platform d’Entreprise afin de supporter tous les cas d’usages d’intégration de données inter-applicative a été lancé.
Missions
Au sein de la Direction de l’Architecture, accompagnement au cadrage et à la mise en œuvre d’une Hybrid Integration Platform (HIP) :
Evangélisation des concepts introduits par l’Hybrid Integration Platform,
Identification des capacités d’intégration à lui faire porter,
Rédaction des Cahiers des Charges et des grilles d’analyse pour le choix d’outils MOM et integration Platform-as-a-Servce (iPaaS)
Pilotage des deux Appels d’Offres (Soumissionnaires, Juridiques, Achat, parties prenantes IT),
Accompagnement sur le design des architectures des socles d’Entreprise MOM et iPaaS,
Benchmark des performances de l’iPaaS Dell Boomi,
Accompagnement des projets Métiers pour accoster sur les nouveaux socles,
Accompagnement pour définir et mettre en œuvre la nouvelle Gouvernance,
Développement de processus iPaaS pour s’intégrer au SI étendu (Kafka en mode SaaS, Data Hub Azure)
Réalisation d’un Proof-Of-Concepts pour tester le paradigm Event Mesh,
Réalisation d’un Proof-Of-Concept pour déployer l’iPaaS en Pointe de Vente.
Bénéfices
Un socle d’intégration d’Entreprise (HIP) up-to-date des best practices d’intégration,
Une gouvernance claire sur le qui fait quoi (gestion des socles infras, développements, gestion des composants d’intégration sur étagère),
Des développements simplifiés
Les autres success stories qui peuvent vous intéresser
Il y a quelques temps, nous avons démarré une saga sur deux sujets qui nous semblaient décorrélés : outils d’Architecture d’Entreprise et Agilité. La question sous-jacente est bien de savoir comment l’outil d’Architecture d’Entreprise peut apporter de la valeur aux équipes opérationnelles, sans perdre pour autant sa simplicité d’utilisation et ses cas d’usage principaux.
De nouveaux acteurs dans le secteur des outils d’Architecture d’Entreprise ont axé leurs efforts sur la facilité de prise en main et la qualité des restitutions à la volée. Un outil facilitant ce travail de manière récurrente peut permettre d’embarquer des utilisateurs « non-architectes », dont l’activité quotidienne est déjà consacrée à 100% à des tâches opérationnelles.
Mais ces nouveaux outils signent-ils pour autant la fin des leaders historiques du marché ? Et surtout, cela signifie-t-il qu’ils doivent être utilisés à des fins plus opérationnelles par les équipes ?
La fin des dinosaures ?
Les outils historiques du marché de l’Architecture d’Entreprise ont été conçus par des experts pour des experts. Et qui en est pleinement satisfait aujourd’hui ? Étant donné leur inertie et la lourdeur de leur configuration, ces outils peuvent exclure les projets et les équipes agiles.
On reproche aux EAMS (Enterprise Architecture Modeling System) d’être des logiciels difficiles d’utilisation, obscurs pour les utilisateurs occasionnels et nécessitant une phase de formation non-négligeable avant utilisation. Trop souvent l’architecte d’entreprise est arrivé avec l’artillerie lourde pour imposer outils et process : c’est tout sauf agile !
Par ailleurs, l’intérêt de l’Agilité est d’apporter rapidement de la valeur au métier, grâce à aux interactions au sein d’équipes mixtes métier/IT. Formés à plusieurs domaines, les développeurs polyvalents sont capables de comprendre les besoins et d’interagir avec les experts pour prendre les meilleures décisions possibles. Cette interaction entre plusieurs disciplines favorise la montée en compétence et enrichit les échanges. De la même façon, des outils déployés par les architectes pour les architectes apportera moins de valeur que s’ils sont ouverts à d’autres domaines d’expertise et améliorés en fonction des enjeux de chacun.
Alors, architectes, puisons notre inspiration des opérationnels et de leurs outils !
Jeune outil deviendra grand
Face aux mastodontes historiques, de nouveaux acteurs ont émergé ces dernières années, jusqu’à devenir de sérieux concurrents. Serait-ce la réponse à l’incompatibilité apparente entre besoins de l’Architecture d’Entreprise et des équipes opérationnelles ?
Certains outils sont de simples modelers. Sans prérequis particuliers de prise en main, ils répondent directement aux besoins de modélisation des projets. Encore faut-il trouver le bon compromis entre la gestion centralisée d’un référentiel d’assets IT et de l’architecture mouvante des projets agiles.
D’autres outils, à peine plus complexes en apparence, gèrent même un référentiel : le principe est d’alimenter l’outil via l’import de données pour générer automatiquement des rapports. Interfacer un outil d’Architecture d’Entreprise et un outil de modélisation est même possible nativement chez certains éditeurs. Ou bien, sous réserve d’avoir quelques « techos » disponibles, une interface « maison » entre l’EAMS et l’outil de modélisation projet (tel Archi, ou autre) permet de dissocier la partie référentielle du projet et de ses changements. Tout cela pour un contenu toujours plus riche, mais structuré !
Nous pensons également aux éditeurs qui intègrent de manière « out-of-the-box » des outils utilisés par les projets, comme la suite Atlassian. En quelques clics sur Confluence, par exemple, il devient possible de partager au sein de l’équipe des diagrammes et roadmaps modélisés dans le logiciel d’AE, de manière dynamique et embarquée. La démarche se veut collaborative : cette interconnexion ferait-elle le pont entre les deux mondes pour finalement mettre tout le monde d’accord ?
Grâce à ces logiciels, il devient possible de centraliser toutes les informations importantes pour les projets et l’entreprise dans une vue unique et partagée. Si le but est de communiquer des informations clés, c’est suffisant. Architectes d’entreprise et équipes agiles échangent leurs connaissances (opérationnelles ou stratégiques, détaillées ou macroscopiques, délimitées ou transverses) pour mener les projets de transformation de l’entreprise au mieux.
L’outil d’AE, l’ouvrir aux opérationnels ou pas ?
Pour garantir la mise à jour régulière du référentiel d’architecture, l’implication des équipes opérationnelles (exploitation, projet, développement, intégration) est indispensable. Car ce sont eux, les « sachants » !
Or, si les équipes opérationnelles ont besoin de connaître l’historique des incidents et évolutions de l’application, ses certificats associés et ses contrats de support, les architectes souhaitent principalement visualiser l’existant et bénéficier d’analyse d’impacts exhaustives sur un périmètre précis.
Pour autant, faut-il que l’outil d’AE se plie aux besoins des équipes opérationnelles pour garantir sa mise à jour effective ?
La réponse à cette question réside dans le fait que pour faire fonctionner un logiciel d’architecture, il faut se focaliser d’abord sur un ou deux cas d’usage majeurs, avant d’en élargir l’utilisation au gré des opportunités et des besoins. Que ce soit un outil flexible succinct ou un imposant dino, il faut revoir à la baisse les attentes vis-à-vis d’un outil d’Architecture d’Entreprise.
L’enjeu est donc de bien cadrer le scope. Votre outil d’Architecture d’Entreprise peut très bien se contenter de renseigner les grands jalons et dates d’atterrissage, afin de donner de la visibilité au métier et à la Direction informatique sur les applications et projets qui vont impacter le Système d’Information.
Dans tous les cas, le niveau de granularité des informations à renseigner reste l’élément le plus structurant pour un tel outil. Savoir quoi renseigner, par qui, jusqu’à quelle maille et surtout à quel moment demeure la clé pour garantir un référentiel cohérent et mis à jour régulièrement.
L’Architecture d’Entreprise en libre-service
N’essayons pas de faire monter les projets sur nos vastes outils d’Architecture d’Entreprise. Soyons clairs, ils ne sont pas adaptés à la capacité et à la philosophie des équipes projets.
Avec un EAMS aussi simple qu’une appli de smartphone (à la navigation fluide, sans formation nécessaire et au contenu aisément partageable), les développeurs membres d’une équipe agile bénéficieraient des apports de l’AE et de sa connaissance du métier, de l’IT comme de l’entreprise dans son ensemble, sans alourdir leur charge.
Peut-être le secret réside-t-il dans la conception à deux entrées de l’outil d’AE : un grain précis et spécialisé pour les équipes opérationnelles et un grain macroscopique pour les responsables de pôle, les architectes et les directeurs (opérations, architecture, études, métier…), gérant les roadmaps et permettant l’alignement du SI sur les besoins du métier.
Architectes et équipes projets, qu’en pensez-vous ?
Edge computing vs cloud computing, deux modèles complémentaires ?
Edge computing versus cloud computing, deux modèles complémentaires?
2 septembre 2020
– 6 min de lecture
Architecture
Mohammed Bouchta
Consultant Senior Architecture
Pendant la dernière décennie, nous avons assisté à la montée en puissance du Cloud Computing dans les nouvelles conceptions d’architecture SI.
Sa flexibilité faisant abstraction de la complexité des infrastructures techniques sous-jacentes (IaaS, PaaS) et son mode de facturation à la consommation (Pay as you go) étaient des atouts suffisants pour convaincre les premiers clients. Mais c’est surtout le développement d’un nombre important de nouveaux services innovants avec une grande valeur ajoutée qui a mené la plupart des entreprises à adopter le Cloud. C’est ainsi par exemple que la grande majorité des entreprises ont pu expérimenter le Big Data, le Machine Learning et l’IA sans avoir à débourser des sommes astronomiques dans le matériel approprié en interne.
Le Cloud a facilité également le développement du secteur de l’IoT, ces objets connectés dotés de capteurs qui envoient leurs données régulièrement à un système central pour les analyser. En effet, le Cloud a fourni une panoplie de services pour absorber toutes les données collectées et une puissance de calcul importante pour les traiter et les analyser.
Cependant, le besoin de prendre des décisions en temps réel sans être tributaire de la latence du Cloud et de la connectivité dans certains cas, donne du fil à retordre aux experts lorsque les sources de données commencent à devenir extrêmement nombreuses.
Ainsi, d’autres besoins beaucoup plus critiques ont émergé en lien avec l’utilisation des objets connectés qui nécessitent des performances importantes en temps réel, et ceci même en mode déconnecté. Nous pouvons le constater par exemple dans les plateformes pétrolières en mer, les chaînes logistiques ou les véhicules connectés qui nécessitent une prise de décision locale en temps réel alors que le partage des données sur le Cloud permettra de faire des analyses plus globales combinant les données reçues, mais sans exigence forte sur le temps de traitement.
Ce sont ces contraintes et d’autres encore comme la sécurité des transmissions et la gestion de l’autonomie, qui ont donné naissance à un nouveau paradigme d’architecture, celui du Edge Computing.
Gartner estime que d’ici 2025, 75% des données seront traitées en dehors du centre de données traditionnel ou du Cloud.¹
Que signifie le edge computing exactement ?
À l’opposé du Cloud Computing qui tend à déplacer tous les traitements dans le Cloud, le Edge Computing vise à rapprocher la puissance de calcul, le stockage et les applications de l’endroit où la donnée a été créée. Cela permet ainsi de pallier les problèmes de connectivité, de latence et les risques liés à la sécurité.
Avec le Edge Computing, l’analyse des données peut se faire directement sur le périphérique qui les a générés, comme par exemple les smartphones ou les objets connectés qui ont des ressources suffisantes. Si l’objet connecté est limité en ressources de calcul, de stockage, de connectivité ou d’énergie, comme dans la majorité des cas, alors c’est une passerelle IoT équipée de ces capacités, qui prend en charge la collecte, la transformation, l’analyse des données et la prise de décision / action.
Cette décentralisation du stockage et du traitement des données permet de répondre aux exigences de la prise de décision en temps réel.
Prenons l’exemple de la voiture autonome dans une situation de danger imminent, nous devons envoyer la globalité des données des capteurs sur un Cloud pour les analyser et attendre que le Cloud renvoie à la voiture les directives à suivre pour éviter l’accident. Même avec toute la puissance de calcul du Cloud, le temps de latence imposé par le réseau peut mener à la catastrophe. Alors qu’avec une analyse des données et une prise de décision locale, en temps réel, la voiture aura une chance d’éviter l’accident.
Ou l’exemple d’une machine dans une chaîne de production qui doit adapter sa vitesse d’action par rapport à plusieurs facteurs environnants qui proviennent des appareils de la chaîne. L’utilisation du Edge Computing au niveau de la Gateway IoT (passerelle) permet de récupérer les données nécessaires des périphériques locaux pour analyser et ajuster la vitesse de la machine en conséquence sans avoir à passer par le Cloud.
L’autre atout majeur du Edge Computing est sa résilience. Le système local peut continuer à fonctionner même s’il y a une défaillance majeure dans le Cloud, dans le réseau ou sur d’autre branche du système.
Toutefois, il ne faut pas croire qu’il est simple de mettre en place ce type d’architecture, bien au contraire. En effet, nous revenons à une architecture distribuée qui nécessite des appareils avec des ressources plus importantes (donc plus chères) et souvent avec des technologies hétérogènes qui doivent s’interfacer ensemble pour communiquer, ce qui complexifie l’administration et la maintenance. Aussi, en stockant les données en local, le problème de sécurité des données est déplacé vers les périphériques qui les stockent. Que ce soient les objets connectés ou la Gateway IoT, ces appareils peuvent être accessibles physiquement et sont donc plus vulnérables à un piratage. Ces périphériques devront se doter d’une politique de sécurité accrue pour s’en prémunir.
Ce changement d’approche a ouvert des opportunités pour les fournisseurs de télécommunications qui développent de nouveaux services liés à la 5G, à l’IoT et à d’autres technologies. Il a poussé les différents acteurs du marché à innover pour proposer des offres plus adaptées au Edge Computing. C’est ainsi que les leaders en matériel informatique comme Cisco, Dell EMC et HP par exemple ont tous mis sur le marché des produits dédiés à ce type d’architecture. Les géants du Cloud ont aussi réagi en force à cette tendance avec une palette de services qui peuvent s’étendre jusqu’aux périphériques connectés pour agir localement sur les données.
D’autre part, les avancées technologiques en matière de microcontrôleurs toujours plus miniaturisés, puissants et avec une consommation réduite de l’énergie, ont permis de faire de l’IA embarquée dans les objets connectés afin d’être plus rapide et efficace dans la prise de décision.
Vers la fin du cloud computing ?
Absolument pas ! Le Cloud a encore de belles années devant lui. En réalité, les deux solutions sont complémentaires et c’est le type de traitement nécessaire, le temps de réponse attendu et les exigences de sécurité qui vont déterminer ce qui doit être traité au niveau du Edge et ce qui doit être envoyé vers le Cloud.
Si nous reprenons le cas de voiture connectée, le Cloud va permettre d’agréger les données envoyées par toutes les voitures afin de les traiter, de les comparer et de faire des analyses approfondies pour optimiser les algorithmes de conduite et le modèle IA à déployer comme nouvelle version du programme embarqué dans les voitures connectées.
En combinant le potentiel de collecte et de l’analyse en temps réel des données du Edge Computing avec la capacité de stockage et la puissance de traitement du Cloud, les objets IoT peuvent être exploités de façon rapide et efficace sans sacrifier les précieuses données analytiques qui pourraient aider à améliorer les services et à stimuler l’innovation.
En conclusion
Il est peu probable que l’avenir de l’infrastructure réseau se situe uniquement dans le Edge ou dans le Cloud, mais plutôt quelque part entre les deux. Il est possible de tirer la meilleure partie de leurs avantages respectifs. Les avantages du Cloud Computing sont évidents, mais pour certaines applications, il est essentiel de rapprocher les données gourmandes en bande passante et les applications sensibles à la latence de l’utilisateur final et de déplacer les processus du Cloud vers le Edge. Cependant, l’adoption généralisée du Edge Computing prendra du temps, car le processus de mise en œuvre d’une telle architecture nécessite une expertise technique approfondie.
En fin de compte, vous devez toujours commencer par bien cibler les usages, les exigences et les contraintes de votre système pour choisir la bonne architecture.
