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.
Il faut que je vous avoue que lorsqu’on me demande sur quelle certification agile je peux former les gens, j’ai parfois un peu honte de dire que je peux le faire sur SAFe avec la Scaled Agile Academy.
Aussi, je m’empresse le plus souvent d’ajouter que je suis aussi formateur licencié Management 3.0. Comme pour me dédouaner.
Cette opposition de genres peut surprendre. Encore plus lorsqu’on connaît également mon penchant pour les organisations plates (pour ne pas dire entreprises libérées) et les interventions et articles que j’ai pu faire à ce sujet.
Pour autant, je ne vois pas cela comme une schizophrénie. Et oui, j’ose le dire, j’aime bien SAFe !
Alors pourquoi SAFe est-il un framework qui crée autant de débats ? Pourquoi est-ce que cela peut sembler honteux d’utiliser SAFe ? Autrement dit, SAFe est-il vraiment agile ?
Je vous propose de décrypter tout cela à travers 9 affirmations. 9 arguments massue trop souvent utilisés pour jeter SAFe en pâture dans la fosse aux lions. 9 critiques à la véracité insuffisamment questionnée.
Non, je ne vous ferai pas le coup des “10 affirmations sur SAFe, la 10éme va vous étonner…” mais restez quand même avec moi jusqu’à la fin ;).
Pour commencer, je reviendrais sur l’une des sentences les plus souvent prononcées à son encontre : “SAFe est trop complexe”.
C’est une affirmation que je peux totalement comprendre. Pour qui a un jour regardé le poster SAFe, cela peut même sembler une évidence, tant on peut se trouver perdu à son premier regard.
Pourtant ce défaut de complexité, au-delà du fait qu’il n’est surtout qu’apparent et s’éclaire grandement quand on appréhende pleinement la logique du framework, est l’une des véritables qualités de SAFe.
Si le framework est compliqué, c’est qu’il imbrique beaucoup de sources de connaissances différentes. Il s’attache à faire le lien entre elles ; ce qui n’est jamais chose facile.
En y regardant de plus près, c’est cependant une manière (mais pas la seule) de construire une véritable approche systémique. Réunir autant de savoirs différents, c’est s’attacher à ce que l’ensemble des aspects de l’équation soient pris en compte. Et de ce point de vue, je pense que c’est le framework qui permet la meilleure vision d’ensemble. On y retrouve du lean startup, du design thinking et de l’UX, du Scrum, du Kanban, du DEVOPS (dont le continuous delivery), du Beyond Budgeting et de la gestion de portefeuille, du Management 3.0, du Lean etc.
On a donc une vision qui n’oublie ni les personnes, ni les pratiques, ni la stratégie, ni le client, ni les environnements, ni le management et ni même la culture !
Donc oui, SAFe peut être complexe (au sens des systèmes complexes), mais c’est une complexité nécessaire. Je citerais d’ailleurs à ce sujet Max Boisot qui dit:
La complexité d’un système doit être en adéquation avec la complexité de l’environnement dans lequel il se trouve.
Max Boisot
The Interaction of Complexity and Management
Cela dit, SAFe ne cherche aucunement à être complet sur l’un ou l’autre de ces composants. Il propose des outils dont il nous laisse en partie le soin d’approfondir le contenu.
Il n’y a par exemple pas d’explication détaillée du Gemba, qui fait partie des éléments inhérents à une approche Kanban. Bien que s’appuyant sur Kanban (et plus largement le Lean), SAFe considère que c’est à nous d’en maîtriser les concepts.
Sur ce sujet, SAFe n’impose d’ailleurs aucune méthode. Pour preuve, même si Kanban est devenu aujourd’hui un pilier important, il était autrefois cantonné à la seule gestion de portefeuille. Jusqu’à la V4 du framework en effet, seul Scrum était utilisé comme moyen de piloter une équipe agile.
SAFe est ainsi un framework qui, en son coeur, encourage la sélection des pratiques et outils. Ce qui nous permet alors de nous adapter à l’environnement auquel nous sommes confrontés. Ce faisant, nous pouvons sélectionner le juste niveau de complexité dont nous avons besoin !
2. SAFe n’a rien inventé (sous-entendu “donc c’est pas bien !”)
[br]Autre objection que l’on entend trop souvent, SAFe n’aurait innové en rien ! C’est tout d’abord un faux reproche. Il est parfois plus utile de relier des savoirs que d’en créer de nouveaux. Je rappellerais d’ailleurs cette citation de Bernard de Chartres reprise par Pascal ou même Newton en leur temps :
Nous sommes comme des nains assis sur des épaules de géants. Si nous voyons plus de choses et plus lointaines qu’eux, ce n’est pas à cause de la perspicacité de notre vue, ni de notre grandeur, c’est parce que nous sommes élevés par eux.
Bernard de Chartres
Metalogicon – Livre III
Pour autant, SAFe est un framework qui a lui aussi apporté sa pierre à l’édifice de l’agilité. L’intégration des savoirs agiles et la proposition d’une représentation cohérente à l’échelle de l’entreprise n’est déjà en soi pas un mince exploit. Quand bien même cela aurait été la seule contribution de SAFe, cela aurait eu de la valeur. Mais SAFe va plus loin. Au-delà de cette mise en cohérence, il amène également ses propres nouveautés.
J’en citerai simplement deux: le PI Planning et l’intégration des architectes au coeur de l’agilité.
Le PI Planning est certainement le plus emblématique des apports de SAFe. Qui aurait pu penser que réunir jusqu’à 125 personnes pendant deux jours était une bonne idée ? Pour autant, cet événement est loin d’être la foire à laquelle on pourrait s’attendre. En vivre un est même bien souvent déterminant pour convaincre une entreprise de s’engager dans SAFe. Et ce quand bien même le PI planning peut justement être l’un des éléments qui auraient tendance à faire peur !
Ce sont d’ailleurs généralement ces mêmes détracteurs du PI planning qui viennent ensuite en faire l’apologie. Ils sont enthousiastes face à l’énergie libérée et l’efficacité avec laquelle les problèmes sont gérés. Ils sont surpris de la transparence et de la vision apportées, heureux de l’engagement suscité.
L’intégration des architectes dans SAFe, même si elle est moins souvent mise en avant est également très intéressante. D’abord elle permet de casser un tabou ! Celui d’une agilité qui ne pourrait pas avoir de vision à moyen terme ou de planification.
En effet, les architectes ont longtemps été les laissés pour compte de l’agilité. Le fait de chercher à obtenir des équipes auto-organisées, autonomes et ayant toutes les compétences pour réaliser le produit a pu être vu comme une critique de leur rôle.
Il faut dire qu’ils avaient fini par être perçus comme un élément de rigidité des organisations. En codifiant les méthodes, outils et langages à utiliser ils venaient entraver les besoins d’adaptation des équipes agiles. La guerre était déclarée.
Pourtant l’autonomie sans vision partagée est la meilleure recette du chaos. Sans celle-ci, il est impossible de créer l’alignement et chacun part dans sa propre direction.
SAFe en intégrant le rôle d’architecte aux différents étages du framework, redonne ce rôle de porteur de sens. Les architectes ne sont plus là pour établir une vision figée de l’organisation, mais une vision évolutive.
Ils viennent donc en soutien des équipes en permettant l’alignement de celles-ci avec des approches dont ils garantissent la cohérence. Ils s’assurent également que si les choix sont ouverts en début de réalisation, ils finissent par se stabiliser avec le temps. Ils permettent ainsi d’éviter l’oscillation permanente qui frappe parfois certaines équipes agiles, incapables de converger vers une solution.
3. SAFe est un framework de command and control
L’idée que SAFe serait en fait une approche de command and control, est peut-être la dernière grande critique que l’on entend régulièrement professée à son égard.
Cette notion d’une approche dictatoriale est sans doute accentuée par le célèbre poster de SAFe. Cette représentation détaillée peut en effet donner l’impression d’un framework très orienté processus. Visuellement, la représentation des différents étages de coordination en se rapprochant des structures pyramidales des sociétés, peut laisser penser à une forme de hiérarchie. Une idée bien ancrée dans l’esprit de certains.
Je soupçonne néanmoins la Scaled Agile Academy de maintenir volontairement une certaine ambiguïté sur le sujet. À travers son poster et sa représentation à étages, SAFe laisse penser à une continuité du fonctionnement hiérarchique de l’Ancien Monde. Un choix qui explique le succès commercial de SAFe. Cette représentation de l’agilité, proche des méthodes traditionnelles, et de nos anciennes croyances, est en effet bien plus rassurante aux yeux des dirigeants.
Malheureusement, cette vision d’un SAFe qui ne nécessiterait pas de changer notre compréhension du monde, mais d’adopter simplement de nouveaux processus est également une des raisons principales d’échec de son implémentation.
SAFe, comme tout framework agile, nécessite savoir-faire et savoir-être. Ce dernier étant essentiel ! N’appliquer bêtement que les processus (le savoir-faire), ne peut donc qu’engendrer un échec.
SAFe nous prévient pourtant dès le départ. Il n’est pas une recette prévue pour une application dans sa globalité. Il doit être adapté. Au-delà même des sous-ensembles directement proposés que sont l’Essential SAFe, le Large Solution SAFe, le Portfolio SAFe ou le Full SAFe. C’est une adaptation qui demande une véritable conscience (au sens de savoir-être) des principes et valeurs de l’agilité.
Pour ma part, il m’arrive assez fréquemment de mettre en place chez mes clients une couche de gestion de portefeuille inspirée du Portfolio SAFe. Alors même que les projets/produits ne nécessitent pas de mécanismes d’agilité à l’échelle. Elle apporte en effet un bénéfice réel à l’organisation par les mécanismes de priorisation des projets/produits qu’elle propose.
SAFe est donc un framework qui, peut-être plus que d’autres, peut facilement être dévoyé et implémenté de manière coercitive. On perd ainsi tout bénéfice d’agilité.
Pour autant, il ne m’a jamais empêché de discuter avec certains clients d’organisations plates alors que nous faisions une implémentation de SAFe. Dans le fond, il n’y a rien d’incompatible à ce qu’une entreprise Opale utilise ce framework.
Si l’on peut certes reprocher l’ambiguïté, SAFe n’en reste pas moins un framework agile. Ce n’est pas SAFe qui est anti-agile, mais ce que nous en faisons qui le transforme en outil de command and control.
4. Les métriques dans SAFe sont un retour vers l’utopie de la prédictibilité
Autre critique que l’on entend surtout parmi les agilistes, SAFe propose une approche des métriques qui peut sembler un peu utopique. Dans un monde complexe (et donc volatile du fait des mécanismes d’émergence), SAFe donne l’impression de chercher à tout prédire. C’est une partie que j’ai personnellement mis un certain temps à maîtriser.
En fait, SAFe ne cherche pas à obtenir un chiffre précis, juste et absolu. Son approche des métriques est un moyen d’éclairer la prise de décision. Autrement dit, c’est un moyen de vérifier nos hypothèses, de détecter les changements éventuels et de s’y adapter le mieux possible.
Prenons pour exemple la mesure de prédictibilité du train, qui se base sur le pourcentage de business value atteinte. Cette mesure n’est pas tant effectuée pour suivre l’avancement de nos engagements que pour déterminer à quel point notre environnement est changeant. On ne cherche pas à savoir si l’on va tenir nos objectifs, mais à ajuster notre manière de piloter en fonction du degré d’incertitude de l’environnement dans lequel on se trouve.
Si parfois l’expérience montre une certaine fiabilité dans l’atteinte de nos engagements, tant mieux ! C’est que nous sommes dans un environnement relativement stable. Nous pouvons alors poursuivre une certaine stratégie d’efficience.
Si au contraire la prédictibilité du train est faible, c’est que notre environnement est extrêmement incertain. Dans ce cas, il ne convient pas de rechercher l’efficience. C’est tout l’inverse. Il faut alors s’attacher à développer nos capacités d’adaptation. Cela veut dire se préserver un maximum d’options, le plus tardivement possible (on pourrait aussi travailler à accroître la stabilité de notre environnement. Tout un challenge !).
Le fait que SAFe repose sur un paradigme de changement se retrouve à la fois dans son fort focus sur la création de valeur et dans la manière dont il la définit.
Dans un contexte où nous ne maîtrisons pas l’évolution de nos écosystèmes, il est en effet essentiel de s’assurer d’investir de manière à ne jamais regretter nos choix. Même si nos prévisions étaient déjouées.
C’est pourquoi SAFe, tout comme l’agilité de manière générale, cherche à travailler en permanence sur les éléments dont nous estimons pouvoir dégager le plus de valeur. Le travail est même découpé d’une manière qui nous permette d’en retirer le maximum de bénéfice, quel que soit le moment où nous devrons procéder à des ajustements.
Autrement dit, face au changement, il s’agit d’être dans une situation où force est de constater que nous n’aurions pas pu mieux nous organiser. Nous n’aurions pas pu créer plus de valeur. Nous n’aurions pas pu mieux limiter nos pertes. À moins évidemment d’avoir eu connaissance du changement à l’avance, mais ce serait là un biais de lecture a posteriori…
Comme je le disais, cette incertitude se retrouve jusque dans la façon dont SAFe définit la valeur. C’est en effet le seul framework à parler d’hypothèses de bénéfices et non de bénéfice tout court.
Il met ainsi en lumière le raccourci trop souvent commis entre la valeur escomptée d’un projet/produit et sa valeur réelle après rencontre avec le marché.
En ajoutant cette notion d’hypothèse, SAFe met en exergue la nécessité de piloter le bénéfice escompté. Dès la réalisation de l’epic hypothesis statement, le framework recommande la définition d’indicateurs de pilotage de la valeur (les leading indicators).
Par la suite, ces KPIs permettront de vérifier la justesse de nos suppositions et de mieux détecter les éventuelles adaptations nécessaires (dans nos priorités comme dans notre stratégie). C’est une approche typiquement Lean Startup dans l’esprit (et une belle utilisation de l’innovation accounting) !
De tout cela on retiendra surtout que SAFe ne cherche pas tant la prédictibilité ou la mesure exacte que l’obtention d’informations suffisantes pour prendre des décisions et les piloter.
5. C’est vraiment compliqué d’évaluer la valeur dans SAFe
Au rang des critiques portées à l’encontre de SAFe, on entend encore celui de la manière dont la valeur y est évaluée. Ce n’est pas sans lien avec les reproches faits au regard de l’apparente précision des métriques et leur illusion de prédictibilité.
Sur ce point, il est essentiel de bien comprendre que lorsque SAFe tâche d’évaluer la valeur d’un élément (notamment avec un WSJF), il n’essaie pas de le faire de manière absolue, mais de manière comparative. En ce sens, il est tout aussi facile de mesurer un WSJF dans un contexte logiciel que de production.
Le Cost of Delay effectif de l’élément A reste certes inconnu, mais sa comparaison avec l’élément B reste relativement facile à réaliser et facilite la décision de prioriser l’un par rapport à l’autre.
En cela nous sommes proches de l’esprit de How to measure anything (de Douglas Hubbard) : il ne s’agit pas d’avoir un chiffre précis, mais bien d’avoir un encadrement de celui-ci par un intervalle de confiance suffisant. Toutes choses étant égales par ailleurs et tous nos biais de mesures et erreurs étant d’une magnitude similaire, nous pouvons ainsi prendre des décisions justes sur la base d’évaluations pareillement fausses.
À ce sujet, j’aime bien évaluer la valeur en m’appuyant sur des mécanismes d’intelligence collective (diversité, décentralisation et indépendance/autonomie suivant James Surrowiecki, l’auteur de La Sagesse des foules).
Pour cela il suffit le plus souvent d’avoir un groupe de personnes suffisamment diversifié et d’utiliser des techniques adaptées de la magic estimation (qui permettent de comparer au plus vite un grand nombre de critères entre eux).
C’est parfois étonnamment rapide. J’ai ainsi pu évaluer le WSJF de près de 80 projets et les prioriser en moins d’une journée avec une dizaine de membres d’un COMEX !
Personnellement, j’apprécie également le côté global de la manière dont SAFe aborde l’évaluation de la valeur. Elle prend en compte aussi bien la user business value (incluant la valeur de satisfaction client) que la valeur liée au coût de ne pas faire (la fameuse Time Criticality) ou la valeur indirecte (réduction de risque et développement d’opportunités futures).
En cela, le framework est plus riche qu’un simple Scrum. Il ne se contente pas de la seule valeur business mais rend explicites d’autres types de valeurs. En retour l’attention constante pour la satisfaction client peut cependant paraître moins évidente.
Ainsi, même si SAFe nous incite à évaluer la valeur sur plusieurs axes, le fait de le faire de manière comparative ne rend pas les choses plus compliquées qu’avec une autre méthode.
6. SAFe, contrairement à LeSS ou au modèle Spotify n’est pas adapté à une démarche produit
On a tendance à penser qu’un framework adapté pour des projets à 125 personnes et plus n’est pas pertinent pour l’adoption d’une démarche produit. C’est là encore une critique que j’ai pu entendre surtout en comparaison avec LeSS ou le modèle Spotify.
On précisera d’abord, comme nous le rappelle Séverin, qu’il n’y a pas de modèle Spotify. Il ne s’agit que d’un retour d’expérience. Une expérimentation dont le bénéfice, même chez Spotify, est aujourd’hui remis en question. Il n’y a rien de magique. Spotify n’a finalement rien fait de plus que de créer une organisation spécifique à son contexte. Si le mot feature teams peut sembler sexy, il ne s’agit pour autant pas d’autre chose que d’une équipe pluridisciplinaire.
Ceci étant posé, SAFe est bien lui aussi un framework construit pour fonctionner dans une démarche produit. C’est sans doute moins visible que dans le framework LeSS, car SAFe se veut plus versatile. Il cherche à la fois à pouvoir définir le fonctionnement d’une organisation complète et à permettre la cohabitation de différentes démarches (y compris donc du cycle en V avec de l’agilité).
La vision produit de SAFe est essentiellement portée par la manière de financer les values stream et l’approche capacitaire qui en découle. À travers cela, SAFe promeut la stabilité des équipes dans le temps.
Il facilite également le suivi des produits tout au long de leur cycle de vie en n’externalisant pas la gestion du run. Dans cette logique, SAFe introduit Kanban comme méthode de gestion au niveau équipe lors de la parution de sa V4. Il permet ainsi un meilleur pilotage d’activités de build et de run simultanées, courantes lorsqu’on travaille sur un produit.
Au niveau équipe, SAFe met également en avant la constitution d’équipes organisées en feature teams avec toutes les compétences (quand c’est possible) pour développer et maintenir l’intégralité du produit.
Cela fait d’ailleurs relativement sourire de voir SAFe opposé au retour d’expérience de Spotify dans la mesure où les équipes pluridisciplinaires sont bien présentes dans le framework (de mémoire au moins depuis la V3 et avec les communautés de pratiques et d’intérêt dès la V4).
Il serait donc temps d’arrêter de déifier le modèle Spotify et de le prendre pour le retour d’expérience qu’il est.
L’organisation en feature teams, l’utilisation de Kanban ou la promotion d’équipes pérennes sont autant d’éléments de SAFe adaptés à une approche produit.
7. SAFe n’est que pour les grosses entreprises
Si l’on arrive à faire face à tous ces arguments anti-SAFe, il en reste encore un qui tient à l’idée que SAFe ne serait de toute façon adapté qu’à de grandes organisations.
Ce n’est pas totalement faux. À moins de 50 personnes sur un projet, SAFe a effectivement peu d’intérêt. Dans ce cas, le surcoût de pilotage nécessaire surpasse le plus souvent les bénéfices obtenus.
De manière générale d’ailleurs, la première règle de l’agilité à l’échelle devrait être de ne pas faire d’agilité à l’échelle !
Trop souvent, on cherche en effet à mettre en place des mécanismes d’agilité à l’échelle pour compenser un manque de rigueur dans l’optimisation du système.
Affronter les problèmes en face est difficile. Changer une culture peut sembler un véritable travail d’Hercule. Rechercher les causes racines d’un problème est bien plus délicat que de trouver un coupable. Aussi, pour ne pas remettre en questions nos habitudes, on s’efforce trop souvent de compenser en ajoutant plus de monde sur le projet ou en essayant d’appliquer le dernier framework à la mode.
Plutôt que de prendre le risque d’adopter une véritable démarche d’amélioration continue et de régler les problèmes qui nous font face, nous choisissons de grandir dans une fuite en avant. Nous cherchons à avoir toujours plus de ressources en espérant que cela va miraculeusement tout résoudre!
Si je me souviens bien, Alistair Cockburn rapportait d’ailleurs cette anecdote : sur un projet, il avait déterminé qu’avec les bonnes personnes, il était réalisable avec 6 développeurs. Comme il ne les avait pas, il lui en fallait 50 !
Cela étant, il y a bien sûr des situations où il est indispensable de faire grandir les projets. C’est là une des forces de SAFe qui propose un système facilement scalable.
J’ai déjà dit qu’il m’arrivait de n’avoir recours qu’à la partie Portfolio du framework, mais il est aussi possible de n’utiliser que l’une ou l’autre des couches. Si vous le souhaitez, vous pouvez parfaitement vous contenter de ne mettre en place qu’un seul train. Non seulement rien ne vous force à tout déployer, mais il sera par ailleurs très facile d’ajouter de nouveaux éléments ultérieurement.
La règle devrait être de ne mettre en place que le strict minimum de processus que vous pensez nécessaire et ceci fait d’en retirer encore ! De manière surprenante, vous vous rendrez compte que même ces éléments que vous pensiez indispensables et que vous venez de supprimer n’ont rien d’obligatoire.
Ainsi, nul besoin d’être un grand groupe du CAC 40 pour utiliser SAFe, le plus important c’est d’adapter et de ne pas vouloir systématiquement utiliser tous les étages de la fusée !
8. Pour faire de l’agilité à l’échelle, il vaut mieux construire son propre framework
À en croire certains SAFe ne serait finalement pas un bon framework d’agilité à l’échelle, car chaque entreprise étant unique il n’est pas possible d’avoir une solution pertinente pour tous. Il vaudrait donc mieux concevoir son propre framework.
C’est d’ailleurs la tendance dans tous les grands groupes. J’ai pu participer à la création de quelques-uns et en observer d’autres. Je dois avouer que cela m’a laissé perplexe…
Certes, on peut se féliciter de voir que même les grands groupes, pourtant peu connus pour leur rapidité à s’adapter, ont fait leur ce principe d’adaptation de l’agilité au contexte. Cependant, je ne peux que constater que tous ces frameworks maison, ne sont en fin de compte que de pâles copies de SAFe. J’ai même pu observer l’intervention de grands noms du conseil qui en créant ces modèles, ne faisaient rien d’autre que recopier SAFe. Parfois, et c’est un comble, ils y ajoutaient même des erreurs !
Il en résulte que toutes ces tentatives de développement d’une solution maison aboutissent souvent à des coûts importants, des délais à rallonge et un framework déjà obsolète au jour de son lancement ! Il n’y a rien de surprenant à cela.
En effet, vouloir dès le début se construire une approche spécifique, c’est le faire au plus mauvais moment. Celui où nous ne maîtrisons ni l’agilité, ni ses conséquences sur notre organisation.
Bien sûr, il y a de nombreux frameworks d’agilité à l’échelle. Mon propos n’est pas de dire que SAFe est le meilleur d’entre eux. Je dirais surtout que c’est probablement le moins pire !
Ce qui est essentiel n’est pas d’en faire une implémentation rigide, mais de le prendre comme point de départ.
C’est un moyen de se construire une expérience de l’agilité à l’échelle au sein de notre organisation et de notre contexte.
Cela n’est en aucun cas un objectif ou une destination !
Alors que nos connaissances sur la nature de notre environnement, nos particularités culturelles et les attentes de nos clients progressent, nous pouvons alors commencer à élaborer nos adaptations en connaissance de cause. Il sera alors temps de concevoir une approche dans un esprit de continuous organization. C’est-à-dire, une entreprise capable de se réinventer et de s’améliorer en permanence.
Ainsi utiliser SAFe comme point de départ est un raccourci intéressant. Cela nous évite de devoir directement construire une approche spécifique, à un moment où notre compréhension des mécanismes est largement insuffisante. Créer son propre modèle quand on n’en a pas la maturité est une perte de temps. Tout comme faire de SAFe une vérité absolue à suivre à la lettre serait une erreur grossière
9. SAFe n’est pas de l’agilité à l’échelle
Quant à la dernière objection à faire à SAFe, c’est à moi d’intervenir et de la soumettre à votre réflexion. Si l’on en revient au coeur du problème qui est la manière de faire de l’agilité à l’échelle, je crois que SAFe, LeSS, DAD et autres Nexus sont tous foncièrement biaisés.
Face aux problématiques d’échelle, tous ces frameworks proposent de gérer la complexité liée à l’augmentation du nombre d’échanges (facteur d’émergence) par ajout de processus (ou mécanismes de coordination).
Ceux-ci peuvent être plus ou moins lourds, ils n’en restent pour autant pas autre chose qu’une forme de procédure. C’est à dire quelque chose par essence figée et qui ne peut être adaptée à toutes les situations.
Multiplier ainsi les processus reviendrait donc à réduire notre capacité d’adaptation.
Sur ce sujet d’ailleurs, il est intéressant de voir combien, dans le domaine militaire, les forces spéciales laissent une grande place à l’autonomie.
Certes, elles sont entraînées à réagir de manière quasi automatique à un grand nombre de situations. N’oublions pas qu’elles interviennent à des moments laissant souvent peu de place à la réflexion. Dans ces contextes, l’automatisme peut faire la différence entre la vie et la mort.
Si nous cherchons réellement à être agile à l’échelle, nous devons donc fuir les règles préétablies.
Dès lors, il s’agit bien de diminuer le nombre de processus pour accroître notre capacité d’adaptation. En effet, plus nous serons nombreux, plus nous multiplierons les interfaces avec nos environnements et plus nous serons fréquemment confrontés au changement. Avec la taille, la nécessité de développer notre faculté d’adaptation gagne en criticité.
Si l’on devait proposer une définition de l’agilité à l’échelle, on pourrait l’écrire ainsi : Être agile à l’échelle, c’est savoir accroître les capacités d’adaptation, de résilience ou d’innovation de l’organisation plus rapidement que sa taille n’augmente.
Sur ce sujet SAFe, tout comme l’ensemble des frameworks d’agilité à l’échelle, de par leurs ajouts de processus au fur et à mesure que l’organisation grandit, ne sont donc pas réellement adaptés…
Mais alors… l’agilité à l’échelle est une utopie ?
Bien sûr que non ! Mais le changement pour y parvenir est loin d’être évident !
Si l’on accepte que l’agilité à l’échelle c’est l’adaptabilité à l’extrême, il existe bel et bien une approche en ce sens.
Si l’on regarde les principes de construction des organisations plates, tels que présentés par Frédéric Laloux dans son livre Reinventing Organizations, on s’aperçoit en effet que c’est précisément cette philosophie qui est à l’oeuvre.
L’entreprise libérée n’est à ce titre ni plus ni moins qu’une société dont la capacité d’adaptation a été poussée à l’extrême. Laisser chacun libre d’entreprendre les actions qui lui semblent les plus justes pour l’entreprise c’est permettre d’agir au plus près du changement. C’est comme de mettre le volume de l’agilité à 11 !
Plus l’entreprise est apte à laisser de l’autonomie à ses collaborateurs, plus elle gagne en agilité.
C’est un chemin qui, s’il peut être séduisant, comporte ses propres embûches !
À commencer par la difficulté à proposer une vision transcendantale, véritable lien de l’organisation qui permette à chacun d’avancer indépendamment dans la même direction.
Sur ce sujet, vous pouvez d’ailleurs tout de suite oublier les visions du type: faire un milliard de chiffre d’affaires ou être le premier sur son marché.
Une vision ne vaut que si elle est partagée et bénéficie à tous. Tant que la poursuite de votre vision ne se traduit pas dans les actes de chacun au sein de l’organisation, vous n’avez pas encore trouvé le bon message.
Ce genre de transformation représente une véritable révolution culturelle et une route ardue.
Vous serez confrontés aux difficultés de la transparence, de l’acceptation des erreurs et de la valorisation de l’apprentissage et de l’expérimentation.
Vous affronterez la perte de repères de l’abandon des statuts et le challenge de la redéfinition des plans de carrière.
Vous devrez construire une entreprise apprenante qui permette le développement de chacun et se réinvente en permanence.
Aller dans cette direction, c’est accepter d’avancer sur un chemin peu emprunté où il vous faudra découvrir vos propres leçons.
De fait, même si un tel mode d’organisation serait finalement une réponse plus pertinente aux problématiques d’échelle dans un monde complexe, le challenge est indéniable.
Il est ainsi souvent plus aisé d’apporter une réponse s’appuyant sur un framework d’agilité à l’échelle que de s’engager sur ce chemin. Quand bien même l’agilité à l’échelle porte ses propres limites.
Il n’y a aucune honte à cela et vous pouvez vous réconcilier avec SAFe.
Et si d’aventure votre coeur d’agiliste vous poussait vers davantage, n’ayez aucun regret.
Comme je l’ai dit et le répète : avec le bon accompagnement, l’un n’est pas nécessairement incompatible avec l’autre.
Si SAFe n’est pas la destination, c’est peut-être néanmoins l’un des meilleurs premiers pas…
Un voyage de mille lieues commence toujours par un premier pas.
Depuis quelques années nous observons une croissance rapide du marché Cloud Public. Les offres Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP) sont arrivées maintenant à maturité.
Une jeune entreprise ou startup qui cherche à déployer une nouvelle application métier ne va même plus considérer d’acheter ou d’opérer des serveurs dans son data center ou via un hébergeur plus traditionnel. Afin de répondre à la demande de certaines entreprises, ces trois leaders sur le marché du Cloud Public ont tous sorti ces dernières années une solution permettant le Cloud Hybride. Mais que valent aujourd’hui ces solutions ? A quels cas d’usage permettent-elles de répondre ? Nous allons tenter de répondre à ces quelques questions dans cet article.
Les différentes stratégies d’adoption ou de migration vers le cloud
Si, pour certaines entreprises, une stratégie Cloud-First basée sur un seul fournisseur peut paraître tentante, celle-ci n’est pas sans risque comme nous l’avons expliqué dans notre article : Les 5 mythes associés à une stratégie Cloud-First.
D’autres vont adopter une stratégie multi-Cloud, c’est-à-dire qu’elles vont retenir les services de plusieurs fournisseurs, qu’ils soient SaaS, PaaS ou IaaS, afin de ne pas mettre tous leurs œufs dans le même panier.
Enfin, certaines ont fait le choix d’adopter une stratégie Cloud Hybride, afin d’avoir la possibilité de déployer l’infrastructure : soit sur une plateforme Cloud Public soit sur leur data center On-Premise, soit sur un Cloud Privé.
Nous allons maintenant vous présenter chacune des solutions proposées par ces trois fournisseurs et vous expliquer leurs différences.
Azure stack
Azure Stack est un portfolio de produits qui existe depuis 2016 et décliné sous forme de 3 solutions : Hub, HCI, Edge.
Azure Stack Hub vous offre la possibilité de déployer vos applications modernes basées en particulier sur des microservices ou des containers On-Premise.
Azure Stack HCI permet de déployer des ressources compute et de stockage pour des bureaux ou des usines qui nécessitent d’avoir des ressources en locales.
Enfin, il existe aussi Azure Stack Edge pour répondre aux cas d’usages nécessitant des capacités d’intelligence Artificielle et de Machine Learning en local.
Chacune de ces solutions n’a pas tout à fait la même couverture fonctionnelle (et le modèle des prix est aussi différent) que les services Cloud associés. Ces offres viennent sans matériel et celui-ci devra être acheté en sus parmi une gamme certifiée par Microsoft.
AWS Outpost
AWS a annoncé la sortie de sa solution Cloud Hybride fin 2019. Cela permet d’exécuter les services EC2, EBS, EMR et bientôt S3 en local. La solution comprend l’infrastructure et est livrée sous la forme d’une appliance. A noter que la solution Outpost ne permet pas de déployer ses services sur les autres fournisseurs Cloud Public.
AWS Snowflake
A noter aussi, ce service qui dans sa version Snowball Edge Storage Optimized permet d’avoir au sein d’un boîtier du stockage par bloc ou objet, de la CPU et un accès à certains algorithmes de Machine Learning. Ceci peut être pratique notamment pour des professionnels dans le multimédia ou la santé ayant besoin de faire des recherches avancées sur le contenu de très large bibliothèques de vidéos ou de photos en local sans avoir à les partager sur des services grands publics sur internet.
Anthos
La solution de Google est basée sur Kubernetes et permet pour des CloudOps familiers avec cet outil de déployer leurs applications basées sur des microservices à la fois On-Premise et sur d’autres fournisseurs Cloud Public.
VMWare
Il ne faut pas oublier que, depuis quelques années, Azure, AWS et Google offrent également la possibilité aux clients utilisant la solution de virtualisation VMWare d’étendre leurs ressources sur le Cloud Public.
IOT
Des solutions IOT mixant des ressources en ligne, Edge et On-Premise sont également disponibles mais celles-ci seront l’objet d’un prochain article.
A quels cas d’usage ou problématiques peuvent répondre ces solutions ?
Ces différentes solutions permettant de faire du Cloud Hybride peuvent être intéressantes pour certains cas d’usage. A titre d’exemples, nous pouvons citer :
Tirer parti de ressources compute, stockage et d’analyse sur des sites ayant besoin de croiser des données avec des systèmes de gestion hébergés en local.
Certains sites ou bureaux (ex : des points de vente) ont besoin d’exécuter des traitements critiques nécessitant des temps de réponses presque immédiats. Cela peut aussi être des transactions qui ne tolèrent pas les problèmes réseaux (ex : encaissement des achats clients).
Dans le cas précis d’Anthos ou d’Azure Stack, cela permet de capitaliser sur vos compétences internes et de pouvoir avoir une seule usine logicielle CI/CD pouvant être déployée sur plusieurs plateformes.
Enfin toutes ces solutions peuvent aussi servir comme option pour les applications nécessitant un Plan de Reprise d’Activité (PRA), pour faciliter vos migrations sur le Cloud Public ou pour faire du débordement pour absorber des pics de charge saisonnier à moindre coût.
Le revers de la médaille de ces solutions est que souvent seuls les services de base (IaaS, CaaS, certaines briques PaaS) sont proposés. Chaque année, les fournisseurs déploient des centaines, voire même des milliers d’innovations sur leurs propres data centers, dont vous ne pourrez pas bénéficier au fil de l’eau sur votre Stack Cloud OnPremise. Les plateformes Big Data ou e-Commerce ayant le plus besoin d’élasticité et de ressources quasi illimitées ne seront pas de bons candidats pour ce mode de déploiement.
Il ne faut pas se tromper, si Microsoft, Google et AWS disposent tous d’une solution pour faire du Cloud Hybride, c’est bien parce qu’il y a une forte demande même si cela permet de répondre à des cas d’usages bien précis. En 2017, la taille du marché pour le Cloud Hybride était estimée à 36 milliards $. Les analystes prévoient que celui-ci atteindra 171 milliards d’ici 2025 ! Alors qui gagnera la course pour dominer ce marché ?
La Data a le vent en poupe. Le monde du digital vous impose de travailler à partir de vos données et il devient de plus en plus exigeant avec celles-ci. Vous avez donc besoin d’augmenter* la valeur propre de vos données (niveau de qualité, accessibilité, connaissance…) afin d’optimiser des usages existants, ou pour répondre à de nouveaux usages et gagner les opportunités business qui assureront le développement de votre entreprise.
La data, un vaste sujet
La direction a décidé que la Data était prioritaire : la grand-messe Data est lancée. Maintenant il faut construire et des sujets clefs commencent à apparaître : modélisation, gouvernance, dictionnaire de données, reprise des données, qualité de données, architecture fonctionnelle, architecture de données, échanges de données.
Des sujets clefs trop souvent sous-estimés : pourquoi ?
Parce que bien souvent, la première idée qui nous vient en tête est qu’une solution du marché existe et répondra à tous ces sujets. Le projet data devient un projet d’intégration SI et bien souvent ce projet est un échec.
Ensuite, parce qu’on ne voit pas à très court terme l’impact de ces sujets sur la maintenance des applications, les performances, la productivité, le time to market, la satisfaction client et les possibilités offertes par vos SI.
C’est la transversalité de la data et les nouveaux usages qui rendent complexes la conception des solutions pour répondre aux besoins adressés par les métiers.
Prenons l’exemple de la modélisation de données
Si vous mélangez le modèle physique et le modèle conceptuel, ou si vous ne comprenez pas bien les concepts fonctionnels manipulés lors des processus métiers, alors votre modèle de données ne répondra pas à tous les besoins adressés.
Et si en plus, les modifications de ce modèle au fur et à mesure des nouveaux besoins adressés ne sont pas suivies et validées de manière transverse par un architecte de données expérimenté, petit à petit, le SI que vous construisez tendra à devenir moins flexible et moins agile face aux besoins qui se multiplient et où vous avez besoin d’aller vite.
Une conséquence est que la conception des portails qui vont utiliser vos données sera plus complexe et pourra avoir des impacts forts sur les performances. Une autre est que vous ne serez pas capable d’absorber les données d’autres SI à l’échelle de l’entreprise (futures acquisitions, futurs décommissionnements pour obsolescence, changement d’architectures, etc.).
La modélisation n’est qu’un exemple
C’est un processus lent et qui ne se voit pas. Face au marché qui ne vous attendra pas, vous serez alors plus lent que les nouvelles demandes qui apparaissent, et vous ne serez pas en mesure de les anticiper. Mal modéliser c’est lentement se créer des blocages SI quand il faudra répondre à de futurs besoins. Adressez donc le sujet modélisation à une personne experte dans votre organisation.
La modélisation est un exemple, mais la gouvernance, la qualité des données, les habilitations sur les données ont des impacts tout aussi similaires.
Exigez le savoir-faire
Donc non tout le monde ne peut pas se décréter Modélisateur, Analyste de données ou Chief Data Officer. Ne lancez pas des projets Data si vous n’avez aucune expérience sur le sujet, ni les compétences nécessaires. Sachez les identifier. L’enjeu se joue au niveau de chaque data utile à un usage. Chaque data manipulée, modélisée, mappée, extraite et exposée sur lesquelles travaillent chacune des personnes qui vont construire votre SI.
Comme pour la modélisation, est-ce que les équipes de vos projets ont l’expérience nécessaire pour visualiser l’impact de leur microdécision à chaque phase de la conception ? Je vous garantis que non !
Des compétences et de l’expérience sont absolument nécessaires pour prendre du recul et traiter le projet selon les exigences spécifiques liées à la data, en plus des besoins des métiers et des exigences SI.
Alors entourez-vous, recrutez les profils qui l’ont déjà fait et cherchez les acteurs du marché** qui sont au fait des dernières technologies, car c’est votre survie digitale qui en dépend !
* Comment valoriser vos données ? Le livre blanc ‘Augmentez la valeur de vos données’ Rhapsodies Conseil est là pour répondre à vos interrogations.
Patrick Juvet nous le rabâchait dans les années 80. Il s’égosillait sur tous les postes radio et nous demandait à tue-tête « Mais dites-moi où sont les femmes ?». Cette chanson est restée à la mode et pour cause ! On est encore en droit de se poser la question, notamment dans le monde du travail et plus particulièrement dans le domaine de l’IT !
Le numérique est un secteur clé, porteur et florissant qui est convoité, voire gouverné par la gente masculine. Alors où sont les femmes pardi ?!
Comment explique-t-on qu’au XXIème siècle, celles-ci ne soient pas aussi présentes que les hommes ? Bien que très discrètes aujourd’hui, on compte pourtant quelques femmes parmi les pionniers de l’ère numérique. C’est en effet Ada Lovelace qui conçoit le premier ordinateur au XIXème siècle ou Grace Hopper qui, au milieu du XXème siècle, invente le premier langage de programmation.
Il y a 30 ans, les femmes occupaient environ 30%des fonctions techniques des métiers du numérique (développement, exploitation, production et gestion de projet). Cette part a été divisée par deux depuis, et on retrouve désormais les femmes principalement sur des postes d’employés administratifs ou de secrétaires plutôt que sur des postes d’ingénieurs ou de techniciens.
Une tendance observée partout dans l’Union Européenne ? D’après « Women in the Digital Age« , une récente étude réalisée pour la Commission Européenne, trois fois plus d’hommes que de femmes travaillent dans le numérique en Europe.
Qu’en est-il en France ?
Et bien les chiffres sont accablants. En effet, plusieurs études ont montré que les femmes représentent seulement 28% des travailleurs des métiers du numérique, dont 16% dédiés à la technique pure et 8% en gestion d’entreprise.
Plusieurs exemples nous prouvent que de nombreux acteurs tentent de remédier à cette situation, le gouvernement en tête de pont.
En 2018, une forte mobilisation de Syntec Numérique ainsi que le soutien d’entreprises, d’associations et du gouvernement, a donné lieu à la création de la fondation Femme Numérique afin de de mieux positionner les femmes sur ce secteur. Cette fondation a quatre objectifs clairs :
Rendre plus visibles et valoriser les femmes dans le numérique : mobiliser un vaste réseau engagé et des personnalités féminines du secteur pour les faire intervenir en tant que “modèles” dans les médias, les écoles, etc.
Favoriser la mixité dans les métiers du numérique : rassembler dans un livre blanc les bonnes pratiques existantes dans de nombreuses entreprises et organisations concernant l’intégration des femmes dans les métiers du numérique.
Sensibiliser les filles aux métiers du numérique : intervenir au plus près des jeunes femmes dans les écoles pour démystifier le numérique et, au travers d’ateliers collaboratifs et de kits pédagogiques, leur donner de l’appétence et le désir de découvrir et s’orienter vers les métiers du numérique.
Attirer dans le numérique les femmes en reconversion ou en évolution de carrière grâce aussi à des formations professionnelles ciblées et adaptées.
Depuis 2019, la loi Avenir professionnelle qui vise entre autres à éradiquer les inégalités entre les hommes et les femmes (d’ici 2022) dans le monde du travail, oblige les entreprises de plus de 1 000 salariés à publier un index d’égalité hommes-femmes.
Par ailleurs, tous les ans au mois d’avril, la Journée de la Femme Digitale met à l’honneur et connecte les femmes qui s’emploient à révolutionner le monde grâce au digital. Ce rendez-vous annuel qui se déroule en Europe et en Afrique a pour ambition d’inspirer, d’encourager les femmes à se révéler et à innover.
Bien que la loi Avenir professionnel ne concerne pas Rhapsodies Conseil, étant un cabinet de moins de 1 000 salariés, nous avons tenu à faire nous aussi cet exercice, par soucis de transparence et parce que l’équité homme-femme nous tient à cœur.
Nos chiffres sont encourageants puisqu’à fin février 2020 nous comptions 60 % d’hommes et 40 % de femmes.
Nous nous sommes intéressés aux femmes du cabinet en recueillant leurs témoignages. Nous avons mené une enquête de terrain auprès de trois “Rhapsodiennes” qui ont eu la gentillesse de nous répondre sur le sujet.
Voici leurs points de vue.
Entretien avec des femmes du numérique
L’appétence des femmes pour le secteur du numérique
Comment vous êtes-vous retrouvées dans le secteur de l’IT ?
Nous avons interrogés trois rhapsodiennes avec des profils très atypiques : Marie Gazal, Aude Ramaen et une troisième personne qui a souhaité garder l’anonymat. L’une ayant fait une formation achat, l’autre ayant même débuté par des études de lettres, puis enchainé par un stage en cabinet de conseil spécialisé en architecture SI. Toutes les trois ont été animées par une appétence commune pour les nouvelles technologies.
En faisant une reprise d’études pour accompagner mes clients dans leur stratégie web, je me suis retrouvée dans une ESN et j’ai compris que c’était un secteur qui me correspondait, car il répond à mon envie d’aider les organisations à grandir et aussi à mon attirance pour tout ce qui touche aux nouvelles technologies.
C’est un secteur qui a besoin d’une vraie expertise technique mais pas seulement. On a aussi besoin de compétences en management, en communication et en conduite du changement.
Ce qui me plaît c’est qu’il s’agit d’un secteur en perpétuel changement, c’est le secteur du futur !
C’est un secteur qui a besoin d’une vraie expertise technique mais pas seulement. On a aussi besoin de compétences en management, en communication et en conduite du changement.
Ce qui me plaît c’est qu’il s’agit d’un secteur en perpétuel changement, c’est le secteur du futur !
Vous voyez-vous toujours dans ce secteur dans 10 ans ?
Ce secteur étant en constante évolution, elles ont bien conscience que même si les problématiques ne seront sûrement pas les mêmes, les clients auront toujours besoin d’accompagnement pour poursuivre ou maintenir leur transformation digitale.
Néanmoins, les préoccupations de demain sont aussi écologiques.
J’espère que le secteur va évoluer ! Je trouve qu’on consomme trop de ressources énergétiques et je souhaiterais orienter ce secteur vers une décroissance énergétique. Mon métier dans quelques années sera architecte SI écologique !
La place de la femme dans le secteur du numérique
A votre avis quelle est la proportion de femmes et d’hommes sur le marché du numérique ?
Le ressenti des consultantes interrogées reste mitigé. Malgré l’impression d’une évolution tendant vers une meilleure parité, le constat reste qu’il y a une forte présence d’hommes comparée aux femmes.
Autant quelques années en arrière j’aurais dit 90 % d’hommes pour 10 % de femmes, mais aujourd’hui j’aurais tendance à dire 70 % d’hommes et 30 % de femmes, ce qui est plutôt une bonne nouvelle !
A quoi est dû ce constat selon vous ?
L’informatique est perçu comme un secteur masculin qui nécessite en plus parfois un diplôme d’ingénieur encore trop délaissé par les femmes. Le problème viendrait donc en amont, d’un faible “recrutement” de femmes au sein des parcours universitaires du digital.
C’est un héritage de la société qui a traditionnellement dit que les femmes avaient plus de compétences sociales que techniques. Les femmes pensent ne pas avoir certaines compétences nécessaires pour exercer des métiers dans l’IT mais selon moi c’est une erreur et un stéréotype qu’il faut faire disparaître.
La compétence n’est pas une question de sexe. Il y a une sorte de machisme ambiant. Il faut qu’on arrête de se jauger par rapport à notre sexe. Par exemple, dans ma mission actuelle, on est 20 en tout et seulement 3 femmes.
Toutefois, la tendance étant à la hausse par rapport aux générations précédentes, nous pouvons peut-être espérer voir grandir notre proportion dans le secteur.
De manière générale, nos expertes déplorent que les femmes ne soient pas plus représentées et cela aussi dans les fonctions les plus hautes.
Vous pensez-vous désavantagées en tant que femmes dans ce secteur, comparées à des hommes avec des compétences et des expériences équivalentes ?
Quel que soit le processus de recrutement (cabinet de conseil, ou client final), elles pensent avoir été jugées clairement sur leurs compétences.
Cependant, elles soulignent tout de même l’existence de discriminations notamment sur les salaires ou le choix des missions, selon le type d’organisation et le niveau de maturité RSE de l’entreprise.
Malheureusement oui je me sens désavantagée en tant que femme, mais cela dépend aussi beaucoup du type d’organisation dans laquelle on se trouve à mon avis et son niveau de maturité en RSE. Depuis que je suis chez Rhapsodies Conseil, je me sens moins lésée qu’auparavant en tant que femme.
Pensez-vous qu’il y ait une égalité homme-femme dans le secteur de l’IT ?
Il y a encore peu de temps, j’ai eu une conversation très intéressante à propos d’un couple travaillant au même poste dans la même entreprise (dans le digital), ayant obtenu le même diplôme et ayant le même âge, mais pas le même salaire. La femme était moins rémunérée que l’homme alors qu’elle avait plus d’ancienneté dans l’entreprise.
Enfin, le troisième point qui revient lorsque l’on parle de l’égalité homme-femme, est ce que l’on appelle couramment le “plafond de verre”.
Peu de femmes atteignent les hautes fonctions dans le secteur, même au niveau du gouvernement, En dehors d’Axelle Lemaire, nous avons vu peu de secrétaires d’état chargés du numérique féminines.
Tendre vers une égalité femme-homme
Comment essayeriez-vous de convaincre une femme qui n’ose pas se lancer dans ce secteur ?
Au delà de relancer l’attractivité du secteur IT pour les femmes, il faut rassurer celles-ci en leur rappelant que ce secteur n’est réservé ni aux “geeks” ni aux hommes.
Etant donné qu’il existe une variété de métiers dans ce secteur, il est toujours possible de trouver un job intéressant. Par exemple, une très grande entreprise française de la distribution que je connais bien a des plans de transformations énormes et nous pourrions faire partie de cette évolution
Des points à améliorer sont aussi soulevés :
Je travaillerais pour un meilleur équilibre vie pro/perso, par exemple pour que les femmes ne soient pas lésées à cause d’une éventuelle grossesse. Il y a parfois une différence entre ce que les entreprises promeuvent et ce qui se passe sur le terrain.
Ce dernier élément soulève une tendance au “Women washing” qui consiste à mettre en avant un discours féministe pour améliorer son image sans changer réellement ses pratiques en interne.
Quelles solutions mettriez-vous en œuvre pour rétablir l’équité ?
Nous pourrions commencer par appliquer la loi du 4 août 2014 pour l’égalité entre les femmes et les hommes.
La transparence des salaires serait une solution qui aiderait à mettre en exergue certains écarts.
Même s’il n’y a pas de solution miracle et qu’il n’est pas facile de chasser certaines habitudes misogynes, il existe tout de même des prises de conscience ; les hommes eux même adoptent un comportement plus égalitaire.
J’ai eu la chance de rencontrer des hommes dans ma carrière qui s’efforçaient de pointer ces comportements et de les condamner. J’ai l’impression que c’est une part grandissante de la population masculine du secteur, c’est assez rassurant pour l’avenir.
Elles arrivent, fièrement et sûrement !
Pour conclure, on voit encore une fois que la faible croissance des femmes dans le secteur IT est surtout due à l’éducation et aux clichés intervenus au fil des générations.
Il y a néanmoins une prise de conscience qui a lieu non seulement du côté des femmes mais aussi du côté de l’Etat qui légifère de plus en plus dans le sens d’une égalité homme/femme tant au niveau de la parité qu’au niveau des salaires et des évolutions de carrière, comme ce fut le cas avec la loi du 4 août 2014 pour l’égalité réelle entre les femmes et les hommes, citée plus haut. En parallèle des mouvements indépendants de sensibilisation et d’actions se multiplient.
La mobilisation de Syntec Numérique qui agit pour aller vers cette égalité, s’étend sur toute la France avec une équipe de déléguées régionales dédiées, qui intervient notamment régulièrement dans les écoles et les lycées et qui participe à de nombreux forums et événements de sensibilisation.
Le 17 décembre 2019, la première “IT Ladies Night” a été organisée au Luxembourg afin de promouvoir le secteur du numérique chez les femmes.
Lors de l’événement GEN (Grand Est Numérique) qui s’est tenu en septembre 2018 à Metz, Mariya Gabriel, la Commissaire européenne du numérique, est également intervenue en faveur des femmes dans l’IT lors de la conférence « L’Europe au féminin : quels défis et perspectives ». La stratégie portée par Mariya Gabriel s’appuie sur trois piliers : combattre les stéréotypes, donner envie aux femmes de poursuivre leurs études dans les filières STEM (Science, Technology, Engineering, Mathematics) et favoriser l’innovation et l’entrepreneuriat féminin.
Une fois cette tendance apparue, il serait étonnant qu’elle s’arrête en plein mouvement. Tout comme le féminisme, l’idée d’une égalité homme femme dans le secteur IT commence à gagner les consciences. De nouvelles directives sont mises en place et on peut imaginer que cette tendance gagneras du terrain, modifiant dans le temps les cultures, les mœurs et les comportements.
Les femmes brandissent le flambeau du changement et ont déjà gagné quelques batailles.
De quoi rassurer notre cher Patrick Juvet : « Où sont les femmes ? »
Elles arrivent, fièrement et sûrement
Merci aux collaboratrices qui ont accepté de nous donner de leur temps pour répondre à notre enquête.
La survenance d’événements imprévus, de périodes de crises avec des temps d’impacts très rapides met à mal les méthodes de prévisions et pilotages traditionnels.
Dans beaucoup de secteurs, le temps et l’énergie consacrés au processus budgétaire classique ont été évalués et remis en cause pour des raisons d’efficacité. Ils sont remplacés aujourd’hui par des process plus court dont l’objectif est avant tout de pouvoir s’adapter à un nombre grandissant d’hypothèses, elles-mêmes fréquemment réévaluées.
Rrolling forecast, rolling budget, continuous budget, perpetual budget, …
Autant d’appellations Anglo-saxonnes pour nommer une nouvelle approche d’anticipation et définition des trajectoires et d’objectifs. Dans des contextes plus incertains, il est nécessaire de gagner en agilité et en efficacité, grâce à des prévisions glissantes sur des périodes plus courtes, mais avec un horizon plus lointain que le traditionnel budget annuel.
La révision régulière permet d’intégrer des données récentes prenant en compte les derniers événements. Elle appréhende mieux la réalité du moment, et facilite la prise de décision.
Chez Rhapsodies Conseil, dans le cadre de notre transformation interne, nous l’avons intégrée dans un processus de revues stratégiques trimestrielles. Chaque « Team Leader », responsable d’une expertise et de son équipe associée, présente ses prévisions glissantes sans se focaliser sur la fin de l’année comptable.
L’intérêt est de ne plus s’attarder sur une multitude de détails et de raisonner sur plusieurs scénarios avec les plans d’actions et mesures associées.
La combinaison avec une approche produits permet par ailleurs de décliner la vision stratégique de manière très opérationnelle : lancement d’une nouvelle offre, approche d’une nouvelle typologie de clientèle, retrait sur un périmètre en déclin sont autant de situations plus rapidement appréhendées dans un cadre de révisions périodiques et prévisions glissantes.
Aller à l’essentiel et se libérer d’une forte pression
L’autre intérêt est d’éviter les effets comportementaux des gestions budgétaires traditionnelles. La pression forte sur un exercice engageant sur une longue période, la démotivation lors de contexte de budgets trop « imposés » par l’organisation hiérarchique ont fait l’objet de nombreuses publications. Sans oublier les « biais budgétaires » : sous- estimation des objectifs, survalorisation des ressources, qui ont souvent généré incompréhension et frustration lors des fameux processus budgétaires.
Comme dans toute démarche, il est nécessaire de rester vigilant face à de potentielles dérives. Ainsi il est indispensable de définir clairement le processus, les attendus, les supports et de ne pas chercher à aller vers trop de granularité.
Se concentrer sur quelques indicateurs clés
L’exercice, répété plusieurs fois dans l’année, doit être simple, rapide et basé sur des indicateurs ciblés afin d’éviter que les équipes ne se perdent dans des évaluations détaillées superflues. La prévision peut être combinée avec une approche OKR* où le suivi de quelques indicateurs permettront d’affiner l’analyse des tendances. Cette combinaison permet de motiver les équipes et de stimuler l’ambition en maintenant une cohérence avec la vision stratégique.
Pour être efficace, les indicateurs doivent être déterminés en fonction du contexte et des enjeux.Par exemple le nombre de nouveaux clients sur un périmètre donné, des indicateurs de notoriété, de développement de compétence, de satisfaction des collaborateurs ou des clients permettent d’illustrer de manière très opérationnelle les leviers clés d’une ambition stratégique en complément des traditionnels indicateurs financiers ou sociaux.
Adapter l’organisation et la préparation
Cette approche nécessite une bonne organisation en amont. Elle est plus efficace dans une démarche collaborative avec un bon niveau de délégation et d’échange au sein des équipes. L’intégration d’outils d’automatisation peut être également un plus. Le point de vigilance est d’éviter que chaque revue soit perçue comme un travail titanesque a répéter régulièrement dont les équipes ne verraient jamais le bout.
Ainsi chez Rhapsodies Conseil nous évaluons et communiquons sur la charge préparatoire tout en limitant au maximum les éléments de présentation.
Le contexte de crise que nous connaissons démontre la complexification du pilotage financier des entreprises. La brutalité dans l’évolution de l’environnement, illustrée dans notre secteur d’activité par des annulations de prestations clients tardives, la nécessité de rassurer les salariés, partenaires et actionnaires face à de tels imprévus, impliquent un pilotage réactif avec une vision précise des impacts court et moyen termes.
L’image des conditions météorologiques difficiles dans un contexte de navigation, évoquée dans le titre de cette publication, illustre la nécessité de décisions rapides basées sur des indicateurs performants tout en gardant la vision moyen et long terme du cap et des jalons.
Notre conviction est que cette démarche permet de gagner en réactivité et souplesse. Combien de budget 2020 « classiques » n’ont plus aucun sens aujourd’hui ?
Cette approche, par une stimulation des différents contributeurs, permet une intégration naturelle de nouveaux scénarios en gardant le cap initial ou en le faisant évoluer.
