En cette période de crise épidémiologique et de confinement, les approches PPM apportent chacune leurs qualités pour affronter les risques. Mais comment se distinguent-elles ?
Risque, incertitude, responsabilité : des visions distinctes selon deux approches
Les circonstances de la crise sanitaire actuelle, sont une occasion pour nous, professionnels des projets, d’être interpellés sur la dimension gestion des risques qui nous est essentielle. Comment est-elle appréhendée selon les approches Traditionnelle et Agile de gestion de produits, de projets et de portefeuilles ? En quoi ces approches sont différentes l’une de l’autre ?
Que l’on fasse cette observation au niveau opérationnel des projets ou au niveau de la supervision du portefeuille des projets, on constate que leurs notions « d’incertitude », de « risque », et de « responsabilité » les déterminent et les distinguent à la fois.
Que l’on parle d’une approche cycle en V, Cascade ou Stage/Gate applicable aux projets elles sont rattachées à une vision traditionnelle de la gestion qui se caractérise par une forte exigence d’anticipation des événements par la planification et le contrôle. A contrario, l’approche Agile est par définition une réponse à l’incertitude grandissante à laquelle font face les projets et portefeuilles de projets. Pour y parvenir, parmi les principes inscrits dans le manifeste Agile, on retrouve l’adaptation par rapport au plan et l’autonomie de décision. Cette posture d’adaptation aux circonstances implique celle de l’aptitude à agir en réaction aux événements et changements qui surviennent dans le déroulement des projets et des produits. Mais, face à la crise sanitaire du Covid-19 et à ses implications à la fois économiques, politiques et sociales que proposeraient ces approches en termes de traitement des risques ? La probabilité de la mise à l’arrêt de la société civile est allée grandissante en moins de deux mois, jusqu’à devenir une réalité aujourd’hui.
Un modèle du risque proactif ou réactif pour y remédier
Si nous sommes tous familiers avec la définition et les modalités classiques de gestion des risques, ce sont les divergences de considération de ce processus de gestion selon ces deux approches qu’il est intéressant d’analyser.
Classiquement, avec l’approche traditionnelle, l’identification, la qualification et la réduction des risques participent de la planification et du pilotage des projets et portefeuilles. Il est essentiel de s’appuyer sur une base de risques déjà identifiée et d’une taxonomie des risques la plus ouverte possible tout en étant spécifique à l’activité de l’entreprise. L’expérience vécue par la Chine et observée pendant les premières semaines de l’année a pu servir de référence à de nombreux chefs de projets pour deux raisons. Elle a relevé progressivement la probabilité de l’épidémie à son niveau maximum pour devenir la réalité que l’on connait. Mais, elle a aussi servi de modèle pour figurer et projeter les impacts de son expansion à un point que personne n’avait encore imaginé. La maturité de chacun face aux risques a donc permis d’atténuer les effets de la criticité de ceux identifiés à mesure que l’épidémie prenait place. Les plans de charge des projets et des portefeuilles ont été révisés et les calendriers aussi.
Pour ce qui est de l’approche Agile, la notion de risque est plus difficile à isoler, puisque son esprit pousse à la réactivité face aux événements. Sans intention d’anticipation dans les projets et les portefeuilles et la continuité de services des équipes produits, le parti pris est celui de traiter des problèmes par l’adaptation des méthodes et des livrables au fil des itérations sans que cela n’en dégrade la qualité, qui constitue son principal levier de décision. En l’absence de culture du risque, les acteurs des équipes Agile s’en remettent plus à l’intuition du groupe qu’à la raison des experts. Qu’en est-il lorsque un à un les membres de l’équipe deviennent indisponibles pour raison médicale ou privée ? Enfin les pratiques rigoureuses de cette approche se retrouvent mises à mal par la perte de l’unité de lieu des acteurs imposée par le confinement et le recours au télétravail. Le leitmotiv du « time to market » pour satisfaire le client est momentanément inaccessible.
La gestion du risque : extension de la responsabilité
La gestion des risques se définit par son exigence d’anticipation des événements pouvant faire obstacle aux objectifs visés. Pour ce faire, il faut convenir d‘hypothèses de réduction de son occurrence et de ses effets qui peuvent prendre la forme de contingences retranscrites dans la planification. Tout le travail des responsables tient à identifier, qualifier et envisager ces mesures de réduction en adéquation avec les moyens à leur disposition.
Dans le cas de l’approche classique, la responsabilité de la culture du risque est portée par la ligne managériale, puisque par délégation, il est du ressort du chef de projet de concevoir et d’animer la trajectoire du projet qui vise le résultat dans les termes annoncés au client. Cette forme de déclinaison de la prospective à l’exercice de la planification s’appuie sur la production de scénarios liés à des opportunités et à des risques auxquels des hypothèses de « survenue » sont associées. Lorsque cet exercice est entretenu tout au long des projets, il implique à son tour une révision régulière pour ajuster les hypothèses en privilégiant le levier de pilotage dominant : le temps, le budget, la valeur client. Reste qu’une telle démarche est très consommatrice de temps et se retrouve, dans les faits, incompatible avec l’accumulation des fonctions des chefs de projet. Néanmoins, dans les circonstances actuelles, la coordination des différentes activités et des prises de décisions, de plus en plus souvent réalisée à distance, ne souffre pas de la mise en place du télétravail comme solution de continuité des activités même si les contingences déterminées à l’engagement des travaux ne seront pas suffisantes.
A l’inverse, dans le cas de l’approche agile, la responsabilité est collectivisée au niveau de l’équipe. Les membres de l’équipe mis en situation d’autonomie basée sur la confiance, se retrouvent porteur chacun d’une part de responsabilité. Cette dernière intègre les considérations de l’incertitude, des évolutions de l’environnement interne et dans une moindre mesure externe. Cependant pour exercer cette responsabilité, c’est par leurs interactions en face à face que leur crédo « on fait avec et la vie continue » leur permet d’assumer et de résoudre les problèmes rencontrés. Dans les circonstances actuelles, le mode projet agile résiste bien de par sa capacité à gérer le chaos, au moins tant qu’il n’est pas rendu inopérant par trop de bouleversements.
Les 2 approches résistent à la crise
En fin de compte, aucun des deux modèles n’est pris en défaut. Si l’un privilégie l’anticipation des opportunités et obstacles à la planification en se donnant les moyens de les réduire, et si l’autre est focalisé sur la capacité à délivrer quelques soient les circonstances sans se préoccuper de prévoir des contingences. Ces deux modèles sont à même de faire face à des événements imprévus.
De son côté le Bureau des Projets compose son propre modèle de gestion de produits, de projets et de portefeuille. Historiquement géré en approche traditionnelle, il adopte quelques éléments des pratiques agiles « façon puzzle » (comme l’effort de développer l’autonomie ou la capacité à innover). Sans reprendre suffisamment les principes des approches dont il s’inspire, pour causes de manque de moyens, de temps, de conviction ou d’appui de la Direction, le bureau projet se contente de mettre en place quelques rôles, artefacts et cérémonies. Mais dans ces conditions sa transformation échoue à interpréter le changement de paradigme qu’elle recherche. Parce que, l’interprétation du traitement des risques dans toutes ses dimensions n’en deviendra ni cohérente ni complète. A qui la faute ?
Globalement, on peut donc être rassuré. Ces deux approches de gestion de projets et portefeuille projets peuvent faire face chacune à leur manière à la crise actuelle, comme les Etats le démontrent à leur niveau. La Chine a pris le parti de la planification de mesures jusqu’à effet complet. Tandis qu’en Europe et notamment en France, la résolution est préférée en réactivité aux constats avec des consignes révisées au fil des itérations de plus en plus rapide à mesure que les faits s’accélèrent.
Dans ces conditions, quel que soit l’approche choisie, il faut convenir qu’il est essentiel de développer collectivement et individuellement une culture du risque aussi légitime que le sont celles de la qualité ou de la valeur client. Elle est indispensable face à l’incertitude grandissante de nos sociétés qui perd jours après jours son insouciance.
La transformation digitale mène les entreprises à rechercher un modèle de gestion de leurs portefeuilles de projets capable d’appréhender les projets « Marathon » (cycle long, cycle en V) autant que les « Sprint » (cycle court, Agile, Lean, Kanban). L’approche « Bimodal IT », introduite par le Gartner, n’a pas fini d’apporter ses réponses aux appels à l’aide des équipes de développement Agile face à un management encore traditionnel.
L’approche « Bimodal IT » pour structurer les projets marathon et les sprint …
En 2014, le Gartner avait identifié avec précision une tension cruciale provenant de la prolifération des demandes IT. Aujourd’hui plus qu’hier, les métiers ont besoin de personnalisations, d’évolutivité et d’efficacité et pas seulement de logiciels et d’applications monolithiques. Pour y répondre, le Gartner, soutien que son approche « Bimodal IT » favorise l’innovation, la transformation digitale des métiers et l’amélioration. En cela, il postule que les organisations informatiques de l’avenir œuvreront selon deux modes distincts. Le mode 1 lié à l’informatique traditionnelle, est axé sur la stabilité et l’efficacité, tandis que le mode 2 qui tient de l’organisation agile est axé sur le time-to-market, l’évolution rapide des applications et, en particulier, l’alignement étroit avec les lignes métiers. Notons que bien souvent l’organisation agile demeure expérimentale pour beaucoup d’entreprises.
… mais comment gouverner un portefeuille constitué de projets si différents ?
En cinq ans, le monde anglosaxon de la gestion de projet a donc résolu la cohabitation des approches cycle en V et cycle agile avec le concept de Bimodal IT. Cependant, l’extension de l’approche à la gestion de programme et de portefeuille de projets est très peu débattue. Est-ce par méconnaissance ou refus de la nouveauté ? Ou parce que cette cohabitation des modèles marathon et sprint est déjà pleinement résolue dans les organisations ? Je vous invite à corriger cette lacune en vous livrant ce qu’il faut en connaitre.
Avec la Transformation Numérique nous sommes entrés dans une période transitoire qui nous conduit à gérer des portefeuilles de projets hybrides (IT traditionnelle / IT digitale). Si de plus en plus les projets IT sont animés en équipes Agile, il n’en est rien des programmes et des portefeuilles de projets toujours gérés selon le modèle classique de pilotage. Aujourd’hui ce modèle n’est plus en capacité de répondre au phénomène d’hybridation des portefeuilles de projets. L’objet et le rythme des activités de transformation des SI n’est plus conciliable avec les pratiques conventionnelles de gestion de portefeuille de projets. Cette course en avant vers toujours plus de flexibilité dans la transformation des organisations face aux innovations des concurrents et aux injonctions réglementaires pousse vers ce concept bimodal qui reprend les meilleures pratiques des deux mondes pour concilier stabilité et flexibilité. Il introduit néanmoins le risque d’exacerber les tensions résultantes d’une cohabitation de deux organisations en silo qui se disputent les ressources et l’influence des investissements.
A défaut, les gestionnaires de projets se retrouvent à faire le grand écart entre pilotage traditionnel de leur portefeuille par les délais et les coûts versus pilotage par la valeur et la qualité. Une équation à la fois organisationnelle, managériale et opérationnelle souvent difficiles à résoudre, d’autant plus lorsque les acteurs sont peu aptes au dialogue. A défaut encore, des Directions métiers décident de créer leurs propres équipes numériques, ce qui se traduit par de nouveaux silos et l’émergence d’une « shadow IT » qui n’est pas sans conséquence (impact sécurité, économique et pérennité de l’IT -désurbanisation du SI et dette technique-).
Un retard de mise en œuvre préjudiciable
L’extension de l’approche bimodale aux programmes et portefeuilles de projets apporterait in fine la capacité de faire travailler les équipes de l’entreprise en étroite collaboration pour atteindre la croissance et la transformation dans le monde numérique qui se dessine.
Les solutions éditeurs, les cadres méthodologiques sont à disposition mais difficilement mis en œuvre dans les organisations. En France personne n’en parle. A qui la faute ? Est-ce dû à la résistance au changement au sein des directions ? Aux lacunes conceptuelles consécutives aux castings des consultants appelés en renforts ? Ou encore à la lenteur à faire le pas vers l’introduction de pratiques agiles au sein des cellules PMO ?
La difficulté à produire une feuille de route IT/Métier et le portefeuille de projets correspondant
Historiquement, la gestion de portefeuille de projets (réalisée par la cellule PPM), est un « lieu » où la stratégie rencontre l’exécution : elle vise à transformer les « ambitions » en « plan d’action » réaliste tout en gérant les investissements et le travail. Avec l’avènement des organisations agiles, de nouvelles frictions sont apparues : cela se traduit par un manque d’harmonisation de la stratégie et de l’exécution, par des décisions d’investissement sous-optimales, par des retards à l’adoption de l’agilité, et finalement par un manque de visibilité pour tous les acteurs.
Dans l’idéal la vocation d’une cellule PPM est de produire de la visibilité sur la contribution de la DSI à la performance de l’entreprise, via l’activité projet. Les métiers étant bien souvent peu enclins à anticiper leurs transformations, c’est souvent un casse-tête pour la DSI de produire une feuille de route pour l’année à venir, un tant soit peu crédible. Pourtant, les métiers devront prochainement reconsidérer leurs relations avec la DSI en devenant responsable de la création de valeur face aux facteurs qui s’imposent (changement de l’économie, évolution des usages et des clients, consumérisation de l’informatique, accélération de la numérisation, nouveaux Business models, raccourcissement des cycles, …). Les entreprises qui réussissent le mieux à franchir le cap sont celles où un dialogue réel métier/IT existe pour l’élaboration de la feuille de route. Il n’y a pas de bons et mauvais élèves, mais l’équilibre qui rend possible le dialogue est si fragile, qu’il ne permet pas souvent de pérenniser l’approche.
En réponse à la problématique de la « bimodalité », les éditeurs ont apporté des réponses dans leurs solutions de Gestion de Portefeuille Projet, mais celles des adaptations organisationnelles et managériales doivent encore être adressées pour que les acteurs sachent utiliser au mieux les outils déployés. Car bien entendu, l’adage « un outil ne résout rien tout seul » se vérifie ici aussi. D’autant que du point de vue méthodologique, plusieurs modèles coexistent au sein des équipes. Modèles, pour lesquels l’assimilation des principes à tous les niveaux de l’organisation nécessite encore des efforts.
3 bonnes pratiques
Trois bonnes pratiques d’intégration prescrites par le Gartner peuvent atténuer les frictions et habiliter l’organisation à innover, prioriser ses investissements et délivrer plus rapidement :
La première concerne la capacité à choisir à partir d’une approche simple le modèle qui convient, basé sur la nature des projets à mener, en combinant stabilité des pratiques et flexibilité des activités. L’astuce, ici, est de préserver un mode de travail pour la recherche de différenciation et d’innovation, et un autre pour la gestion courante des projets. Pour y parvenir, mettre l’accent sur l’enjeu de création de valeur des projets est un début.
La deuxième vise à définir des objectifs d’industrialisation. Ainsi, l’organisation peut intégrer des méthodes Agile avec des méthodes traditionnelles sans sacrifier la visibilité pour les décideurs et la communication des métriques malgré les disparités d’unités de mesure. Pour ce faire, il faut déterminer des métriques précises (objectifs et résultats clés attendus), puis se focaliser sur des points très spécifiques et suivre leur amélioration au fil du temps. En effet, il ne peut y avoir d’amélioration sans mesure régulière.
Enfin, la troisièmepratiqueimplique de séparer clairement les collaborateurs en deux groupes distincts : l’un capable d’effectuer les changements au niveau de la gestion de projet ; l’autre qui sache prendre des décisions transverses à l’ensemble du portefeuille de l’entreprise. Cette distinction apporte une clarification des attributions des intervenants tout en réduisant la dépendance liée aux individus. Il s’agit, ici, de conjuguer délégation et subsidiarité dans un même environnement.
Développer une gestion de portefeuille de projet qui pilote aussi les opportunités
Pour relever ces nouveaux défis, les cellule PPM trouvent dans l’approche bimodale, un cadre de gestion du portefeuille de projets actualisé qui intègre des pratiques agiles, fournit des précisions aux équipes de projet sur la façon de communiquer l’avancement du projet, et apporte à la direction générale la prévisibilité et la responsabilisation des intervenants. C’est ainsi que l’approche bimodale est à même d’encadrer les interactions des acteurs pour éviter de compromettre tous les processus d’évolution des métiers par la cohabitation de deux organisations l’une centrée sur le client tandis que l’autre est axé sur la planification et le reporting. Cette forme de gestion du portefeuille met donc l’accent sur les opportunités (opportunités IT autant que métiers), pour tout ou partie des activités de l’entreprise, indépendamment du mode de livraison (traditionnel, agile ou hybride). Ainsi elle facilite les prises de décisions décentralisées, les analyses de rentabilité, les planning itératifs avec des objectifs décentralisés, et utilise des mesures factuelles et des jalons. Enfin autant que possible, les opportunités seront portées par des équipes agiles permanentes (squads).
En résumé, l’approche bimodale permet de résoudre les effets néfastes de la cohabitation des modèles, sans risquer de perdre la stabilité et la flexibilité qui leurs sont chère. Le mode 1 « Marathonien » leur permettra de conserver cette stabilité en faisant évoluer l’infrastructure existante de manière pérenne. Le mode 2 « Sprinter » leur permettra de développer rapidement de nouvelles solutions grâce à sa flexibilité. La transformation de l’organisation pourra être conduite en profondeur sur cette base. Elle passe avant tout par un changement culturel au sein de l’entreprise.
Après notre panorama 360° sur l’IoT dans notre précédente série de publications, nous entrons comme promis dans une nouvelle série d’articles plus opérationnelle pour accompagner vos premiers pas dans le monde de l’IoT.
Aujourd’hui, nous vous proposons d’incarner un(e) responsable Digital, néophyte sur les sujets IoT, faisant face à l’émergence interne de cas d’usage métier sans réponse :
Automatiser le réapprovisionnement de clients B2B en consommables (bouteilles de gaz/oxygène…) sur la base de leur consommation réelle et prédictive,
Suivre l’envoi de marchandise de bout en bout : de la fabrication à la réception par le client.
Afin de booster la transformation métier, notre responsable (oui c’est bien vous) se donne pour objectif de rapidement expérimenter une gamme de services basés sur le traitement de données terrain récoltées par des objets IoT.
Le hic ?
Cette entreprise ne dispose d’aucune connaissance ou compétence dans le domaine de l’IoT. Il s’agit ici de leurs premiers cas d’usage sur ces technologies. Autant dire que notre responsable digital est plutôt perdu(e) à ce stade et ne sait pas réellement par quel bout traiter la demande : comment partager les responsabilités entre IT et Métier ? Quels sont les maillons d’une chaîne IoT ? Make or Buy ? Comment concevoir l’objet connecté ? …
Rassurez-vous, cher(e) responsable digital, nous sommes ici pour répondre à vos interrogations et vous guider dans la réalisation de ce challenge.
Principe #1 : Rester “business focus” en réalisant un proof of value (pov) de quelques semaines
L’IoT, au delà de sa dimension technique, doit avant tout répondre à un enjeu business.
Une phase d’idéation avec le métier est nécessaire pour détourer le cas d’usage et affiner la valeur métier recherchée pour soi et/ou pour ses clients.
Le but premier de cette démarche est de se focaliser sur les éléments à valeur probante et d’occulter temporairement toutes les problématiques techniques. Nous ne visons pas ici l’industrialisation … nous visons uniquement l’expérimentation ciblée, la démonstration de la valeur par l’exemple.
Aussi nous nous focaliserons davantage sur les questions de fond :
Quel est l’existant (processus, équipements, données…) à intégrer ?
Qui est le client final ?
Quelle est l’objectif recherché et la valeur à atteindre ?
Quelle(s) donnée(s) dois-je récupérer / exposer pour y arriver ?
… Plutôt que sur les détails :
Quelles sont toutes les contraintes : environnement, connectivité, form factor, …
Principe #2 : Utiliser les accélérateurs du marché … miser sur l’IoT-as-a-service
La chaîne IoT (objet, connectivité, plateforme IoT, SI entreprise) est longue, complexe et varie en fonction des cas d’usage adressés et de leurs contraintes.
Notre responsable Digital en a eu le vertige !
Start slow…
Comme mentionné précédemment, la phase de PoV ne doit pas s’attarder sur toutes les considérations techniques :
L’objet : concevoir un prototype simple qui sait capter et transmettre des informations. Soit à base de capteurs existants sur le marché … soit en réalisant son propre objet connecté en “une demie journée” : littlebits, raspberry / arduino et la diversité des sondes sont vos amis. Ne vous préoccupez pas à ce stade de la puissance, du form factor à respecter, de l’autonomie ou des enjeux de sécurité.
La connectivité : restreindre son choix à un seul réseau (que ce soit le LPWAN, un protocole domotique ou directement le WiFi) simple à mettre en oeuvre pour vous. Ne cherchez pas à pouvoir fonctionner en mode dégradé / en mode déconnecté / à switcher sur un réseau secondaire si le primaire est indisponible.
La plateforme : utiliser les offres As-A-Service sur étagère, notamment celles des Cloud Providers. Ces offres ont l’avantage d’être déployables en quelques clics, d’être à l’état de l’art, d’être potentiellement gratuite (free tiers) pour faire un PoC. Exemples : AWS IoT Core, Azure IoT et Azure IoT Central, GCP Cloud IoT, …
SI Enterprise : ne pas chercher tout de suite à propager les données IoT dans les méandres de votre SI. Misez plutôt sur les capacités de restitution intégrées à votre plateforme IoT, elles seront suffisantes pour montrer la valeur générée..
… fast PoV !
Principe #3 : Capitaliser aussi bien sur le succès que sur l’échec des PoV
Comme dans tout bon projet SI, que ce premier PoV soit un succès ou un échec, il faudra capitaliser dessus. L’échec est riche d’enseignements et il faut savoir rebondir : “Le projet est mort … Vive le projet”.
Un diagnostic post-mortem vous permettra de prendre du recul sur les activités menées :
Est-ce que le cas d’usage a bien été défini ? Quel questionnement rajouter en phase de cadrage pour être plus pertinent et percutant ?
Quelles ont été les facilités et les difficultés de mise en oeuvre ?
Quelles compétences nous manque-t-il ?
Comment mieux faire la prochaine fois ?
Le premier objectif est de mettre en lumière la démarche réalisée, les conclusions et la valeur apportée pour rayonner ensuite auprès des autres Métiers et les embarquer dans une spirale vertueuse : Fast PoV UC#1 -> Amélioration continue -> Fast PoV UC#2 -> …
Le second objectif, au fil des itérations, sera de fédérer plus large, d’onboarder d’autres Métiers et disposer d’un sponsorship fort afin de créer une Gouvernance IoT à l’échelle de l’Entreprise…
Pour aller plus loin : Le passage à l’industrialisation et la mise en place d’une gouvernance IoT
Félicitations ! Vous avez pu mener à bien plusieurs expérimentations IoT à forte valeur sur des cas d’usages divers et variés, si bien que les sollicitations ne cessent d’arriver !
C’est le moment de passer au niveau supérieur ! Vers l’industrialisation de l’IoT et au delà, la mise en place d’une gouvernance d’entreprise.
Cette étape importante n’en est pas moins complexe tant dans son appréhension et sa préparation que sa mise en œuvre.
Rassurez-vous, nous vous accompagnerons également dans cette démarche lors de nos prochains articles dédiés à ces sujets ! Stay tuned !
Dans un précédent article, nous vous présentions le dernier né des plateformes d’intégration : l’iPaaS. Cette solution s’ajoute à une liste déjà longue comme le bras.
#Batch, #MFT, #ETL, #EAI, #ESB, #EDI, #API, #MOM, #iPaaS … que faire en 2019 dans cette jungle de solutions d’intermédiation ?
Les exigences Business (innovation, écosystème d’affaire, Time To Market, instantanéité de la donnée, …) poussent l’IT à se dépasser en traitant des problématiques d’intégration de plus en plus complexes. Et cela va crescendo le temps passant. Gartner présage même une très forte augmentation (+50%) du marché de l’intégration sur les 5 prochaines années.
Malgré les efforts déployés, l’organisation IT ne permet pas toujours de répondre dans le temps imparti aux besoins du métier. A défaut d’avoir une offre d’intégration Self-Service orientée Citizen Integrator (profil non expert souhaitant réaliser des intégrations simples), ces derniers passent du côté obscur du Shadow IT.
Fort de ces constats, les cabinets d’analyste remettent les compteurs à zéro et recommandent d’adopter une stratégie d’Hybrid Integration Platform (HIP).
Kézako ? Sur quelles solutions miser pour couvrir tous ses besoins d’intégration tout en ayant un objectif de rationalisation ? Comment les décliner dans son organisation ?
Rappel des nouvelles contraintes d’intermédiation
Vente, gestion des stocks, publicités ciblées, connaissance client, campagne marketing, […] … tous les processusmétier (front, middle ou back) doivent être gérés au cordeau (en qualité, en rapidité, au bon moment, …) pour qu’au bout du bout l’expérience client soit sans couture.
Pour cela, l’heure est à la Data : Data centric, cold/hot Data, Data stream, Data processor, Data privacy… de la Data en veux-tu en voilà. La Data en tant que FUEL pour l’Entreprise. Aliment de base qu’il faut capter, qualifier, transformer, raffiner, normaliser, enrichir et transporter vers tous les organes du SI.
Ce dernier point est primordial. Nul doute que le métier boudera si vous n’avez pas les bons outils pour traiter, transporter et mettre à disposition la donnée, aussi qualitative puisse-t-elle être.
Il est presque révolu (enfin sur le papier, car il en existe encore beaucoup dans le SI des entreprises) le temps du gros batch de nuit qui tourne à 5h en fin de plan de PROD pour synchroniser les données dans tous les applicatifs monolithiques on-premise des domaines métiers.
De nos jours :
Le Cloud s’impose et contribue à distribuer les SI,
L’Event Driven Architecture est désormais reine dans l’art de propager la donnée fraîche à qui veut bien la consommer,
L’IoT contribue à l’explosion du volume des données, à l’hyper personnalisation de l’expérience client et impose de savoir ingérer, traiter, actionner et partager de l’information en quasi temps réel,
Les API REST sont la base pour offrir des prises d’accès simplifiées et sécurisées au SI ultra bunkerisés,
# …
Malheureusement, la plateforme d’intermédiation centrale unifiée qui saurait tout bien faire à 100% n’est pas encore née !
Qu’à celà ne tienne …
… Un brin de Transformation, un zest de Pub/Sub … ou l’importance de séparer les capacités d’intermédiation pour faire son propre cocktail d’Hybrid Integration Platform
Vous l’avez compris…
Tout n’est pas synchrone, tout n’est pas asynchrone,
Tout n’est pas fichier, tout n’est pas service, tout n’est pas message,
Tout n’est pas normalisé, tout n’est pas au format SAP,
Tout n’est pas disponible sur le même plan d’adressage IP,
Tout n’est pas privé et tout ne doit pas être exposé au grand public,
Tout ne fait pas 5 octets, tout ne fait pas 4Go,
…
… En fonction de son SI et de ses besoins passés, présents et futurs, il convient d’identifier les fonctions d’intermédiation nécessaires et suffisantes pour couvrir tous les cas d’usages Data.
Une fois cette cartographie détaillée établie, il convient d’analyser quel puzzle de solutions de Data Integration du marché est le plus optimum pour couvrir tous vos besoins en évitant les redondances fonctionnelles et les surcoûts associés.
Pour certains, un couple “iPaaS + API” suffira, pour d’autres ça sera “MOM + API”, il n’y a pas de règles prédéfinies à l’avance…
Cependant le tiercé gagnant selon nous…
Notre recette Data Integration jeunesse et vitalité serait :
#Un socle MOM d’Entreprise pour gérer tous les échanges internes asynchrones orientés messages qui prennent une place prépondérante dans les nouvelles architectures (Pub/Sub, Fan-Out, CQRS, …). Dans l’idéal la solution retenue sera de type Event Mesh pour créer un réseau de broker distribué au plus près des applications.
# Un socle API Management d’Entreprise pour gérer l’exposition (privé, public) de vos services et ressources métiers. Au menu du cycle de vie d’une API: conception, documentation, exposition, sécurisation, gestion des versions, gestion des quota, facturation, catalogue des API, animation d’une communauté privé / publique.
# Un socle iPaaS d’Entreprise pour tout le reste : échange avec l’extérieur, échange Cloud2Cloud, besoin de transformer, nécessité de composer ou d’orchestrer des processus… l’iPaaS fait des miracles (consulter notre article sur le sujet).
Cependant, la Rolls-Royce des plateformes sans Pilote (gouvernance, centre d’excellence) ne vous mènera pas au nirvana de la Data Integration.
Remettre la DSI devant ses responsabilités et ses engagements d’agilité (T2M) vis-à-vis des métiers
Nous avons tendance à accorder beaucoup de place aux Appels d’Offres solutions, à leur couverture fonctionnelle et non fonctionnelle … mais trop peu de temps et d’énergie à la gouvernance et à la gestion des compétences autour de celles-ci.
Quelle erreur… à laquelle la vision stratégique Hybrid Integration Platform compte bien remédier.
Une fois les différentes pièces techniques du Puzzle Data Integration assemblées, pour dévoiler tout son potentiel ce dernier à besoin :
# D’un Centre d’Excellence composé d’un pilote unique, de MOA, d’architectes, d’experts de l’intégration, du développement et de la production. Son rôle sera de veiller au bon fonctionnement de la plateforme, veiller à son MCO, créer des patterns d’intégration et autres composants réutilisables sur étagère, accompagner les domaines métiers, …
# Des métiers eux mêmes qui pourront utiliser les outils orientés Citizen Integrator pour soit réutiliser les composants d’intégration validés en central soit créer rapidement leurs propres processus d’intégration et les mettre en production sous réserve d’approbation par qui de droit.
La stratégie Hybrid Integration Platform vise à créer une plateforme d’intégration unique et sur mesure à votre contexte tant sur le plan technologique que sur le plan organisationnel.
La performance de l’ensemble n’étant viable que si les bonnes fonctionnalités d’intermédiations ont été sélectionnées et intégrées dans un tout cohérent, avec le bon niveau de Gouvernance en central et dans les différents Domaines Métiers.
Dans notre précédent article, nous avons introduit l’Internet Of Things (IoT) et ses cas d’applications phares.
Les quelques lignes ci-dessous vous dressent un portrait de la chaîne IoT et de ses acteurs. Historiquement plutôt réservé à un marché de niche exploité par un écosystème de startups, le marché de l’IoT est en complète effervescence depuis plusieurs années.
Pour y regarder de plus près, prenons chacun des trois grands segments principaux qui le compose.
Les objets connectés
Le marché des objets connectés pour les particuliers est dominé par les startups qui ont su tirer profit de l’IoT dès ses premiers pas. Nous citerons par exemple des acteurs tels que NETATMO, FITBIT, NEST (racheté par Google en 2014) ou encore Withings.
Pour le marché professionnel, on distingue les acteurs historiques du #M2M (Machine to Machine) tels que LeGrand ou Schneider Electric qui ont vu en l’IoT une opportunité de compléter leurs positionnement et se rapprocher encore plus de leurs clients. Mais aussi, des acteurs industriels spécialisés dans le développement et la distributions de capteurs et puces IoT tels que Bosch, Samsung ou encore Siemens.
La connectivité
Sur le volet de la connectivité, le marché est tout aussi divisé, vous vous en doutiez, non ?
D’un côté les réseaux à faible consommation spécialisés pour les besoins IoT nommées #LPWAN (Low Power Wide Area Network) avec deux acteurs ou plutôt deux technologies qui sont massivement déployées sur le marché : Sigfox et LoRa.
#Sigfox, opérateur télécom français crée en 2014 et qui propose sa propre technologie propriétaire.
#LoRa, une modulation des ondes radio open source exploitable par toute entreprise dès lors qu’elle achète des puces de communications LoRa rattaché au réseau #LoRaWan distribué au travers de l’ “#Alliance LoRa”. Cette technologie est exploitée par les grands opérateurs historiques, en particulier Orange et Bouygues Telecom.
De l’autre, les technologies télécom classiques mobiles 2, 3, 4 et bientôt 5G, les réseaux domotiques comme #Zigbee ou #Wave ou encore l’infrarouge, le bluetooth, le Wifi etc.
Nous aurons tout le loisir de détailler les technologies citées et bien d’autres dans notre prochain article dédié à la #Connectivité IoT.
Les plateformes IoT
Le marché des plateformes IoT est certainement celui qui est le plus vaste en terme de représentation et de typologies d’offres différentes.
Quel est le rôle d’une plateforme IoT ? Quelles fonctionnalités critiques doit-elle adresser ?
Domaines d’expertises critiques portés par la plateforme IoT :
Authentification et gestion des objets connectés : authentification et gestion des habilitations, appairage et révocation, supervision et monitoring, maintien en condition opérationnelle (mise à jour, maintenance…), référentiel des objets.
Collecte, analyse et traitement des données : ingestion du stream de données, traitement par flux / lot, historisation et premier niveau de stockage, corrélation événementielle via des règles définies, gestion de scénarios enregistrés.
Exposition des données : gestion événementielle avec des briques externes (SI legacy, plateforme Data Management…), exposition des données (API, Web Services…).
Pour appréhender le marché, divisons les offres en deux grandes familles :
Les Plateformes dites “horizontales” ou “généralistes” couvrent les besoins de manière transversale. C’est à dire, mettent à disposition des fonctions et services pouvant être déclinés sur tous (ou presque) les cas d’usages IoT. Ces plateformes deviennent très utiles lorsque l’on multiplie les cas d’usages, nombre et typologies d’objets, réseaux utilisés, points de collecte et d’exposition des données, afin d’en faciliter la gestion au quotidien (règles et processus de « device management », standards de formats de communication, APIs etc.) et permettre de conserver une cohérence globale. Dans cette catégorie, nous retrouvons tout d’abord les #Pure Players IoT. Mais également les grands acteurs #Cloud qui proposent des offres packagées et brandées IoT se basant sur leurs services managés.
Les Plateformes “verticales” disposent d’une expertise sur un secteur d’activité défini (immobilier, télémétrie, santé…). Elles jouent le rôle d’accélérateur métier fort dans l’analyse et l’exploitation des données IoT. Elles disposent par exemple d’algorithmes et de fonctions de traitement complexes pré-intégrées évitant ainsi à leur client de devoir porter ce développement en interne.
Le marché de l’IoT est en pleine effervescence, entre émergence de startups innovantes, rachats et partenariats, développement de nouvelles technologies (objets et communications), les transformations sont constantes. Le marché n’est pas mature, il n’est pas pertinent de tenter d’établir des règles préétablies applicables dans tous les cas.
Aussi, il faut repenser la démarche et rester dans un modèle au plus près des cas d’usages métier ! Dans un contexte marché dynamique, multipliant les cas d’usages, ne conviendrait-il pas de casser les conventions et de s’orienter vers une approche #multi-plateformes ?
Nous tenterons d’y voir plus clair et rentrerons plus en profondeur dans le détail des typologies d’offres, différents hébergements proposés, critères de comparaisons, typologies d’architectures et modèles opérationnels, modèles financiers et bien d’autres indicateurs déterminants dans notre article dédié aux #Plateformes IoT à venir.
Le prochain, et dernier volet de nos articles 360° sur l’IoT mettra en lumière les promesses faites par la technologie… mais nous nous attarderons surtout sur les points d’attention à ne pas négliger.
