Maturité 365 — Compétence de la personnalisation et du développement

L’information s’appuie historiquement sur un développement « en profondeur » ou «pro» pour créer des solutions d’entreprise. Toutes les lacunes dans la disponibilité de ces compétences ont généralement été comblées par des approches « de l’informatique fantôme » et des applications non gérées.

Au fil des années, à mesure que les plateformes évoluaient, il est devenu de plus en plus possible de fournir des applications viables sans code. Aujourd’hui, il existe un continuum allant de l’out of the box, en passant par la configuration (No Code),jusqu’au développeur citoyen (Low Code) et enfin au développement « correct » (Pro Code). Les outils de gestion traditionnellement associés au développement Pro Code offrent progressivement l’opportunité d’y inclure la rigueur du développement autour des approches No Code et Low Code. La séparation entre ces étages peut ainsi être moins prononcée.

En parallèle, même les produits et services prêts à l’emploi demandent souvent de prendre en charge de la personnalisation et des extensions. Les moyens d’y parvenir varient considérablement, y compris l’interaction via les interfaces de programmation d’applications (API), le codage « superposition » de l’interface utilisateur, la configuration approfondie, les compléments et plus encore.

De plus en plus, les solutions basées sur l’apprentissage et l’intelligence artificielle ont le même fonctionnement que le développement de solutions logicielles, qui offrent également un chemin continu à travers la configuration, le développement professionnel axé sur le Low Code et la science des données.

Définition de la compétence de la personnalisation et du développement

Cette compétence prend en compte les processus de gestion et de gouvernance requis pour différentes approches de développement de solutions et comment combiner efficacement ces différentes approches.

Les concepts de personnalisation et de développement ont évolué dans l’histoire de l’informatique, ainsi que dans l’univers Microsoft 365. Au début de SharePoint, par exemple, presque toutes les organisations se sont retrouvées à développer des solutions Pro Code pour que la plateforme fonctionne en fonction de leur besoin d’affaires. Avec l’apprentissage, Microsoft 365 offre maintenant une grande variété d’applications et de services qui répondent à de nombreux besoins dès la sortie de la boîte ou avec une configuration minimale.

La capacité d’étendre à toute l’entreprise la plateforme Microsoft M365 a également considérablement changé. Plutôt que d’écrire du code qui est empaqueté et déployé sur le serveur, presque tout le développement personnalisé pour Microsoft 365 est effectué à l’aide de scripts côté client, d’extensions via des plateformes SaaS telles que Microsoft Azure. Le SharePoint Framework (SPFx) permet de créer des solutions pour SharePoint, Microsoft Teams, Microsoft Outlook et potentiellement d’autres produits à l’avenir, s’étendant potentiellement à d’autres produits Microsoft. En outre, le modèle de complément Office utilise également des méthodes de script côté client pour étendre les applications Office. Et enfin, Microsoft Graph offre une couche API qui expose une grande partie du paysage Microsoft 365 pour aider à créer des solutions robustes et intégrées à travers les charges de travail.

De nos jours, il est aussi important de savoir s’il faut personnaliser une solution que de connaître le moyen de la personnaliser. Le codage personnalisé a sa place dans Microsoft 365, comme toutes autres solutions. Dans de nombreux cas, la plateforme fournit des outils robustes qui ne nécessitent qu’une certaine configuration pour répondre à vos besoins.

Les outils de la personnalisation et du développement M365

Les outils les plus utilisés pour le développement sont :

• Microsoft Graph
• Microsoft Azure
• SharePoint Framework
• Power Platform
• Dataverse pour Teams
• Microsoft Teams App Source
• Technologique Cloud
• Azure DevOps
• Intelligence artificielle/Machine Learning
• Microsoft PnP Frameworks

Les produits et services personnalisables sont:

• Microsoft Teams
• SharePoint
• Forms
• Project
• Dynamics
• Microsoft Office apps
• Outlook/Exchange Server
• Visio
• Microsoft Lists
• Power BI

Évolution de la compétence de la personnalisation et du développement

Voici un survol des niveaux de maturité pour cette compétence. Pour revoir la description de chacun des niveaux, voir notre article Introduction: les modèles de maturité Microsoft 365.

Niveau 100: Point de départ

Le continuum de la personnalisation et du développement est mal compris, non géré et chaotique. Le personnel est frustré par une mauvaise fonctionnalité, mais n’a aucun mécanisme pour demander ou mettre en œuvre des changements. Le développement se caractérise par la construction en direct sans passer par un processus de publication où le développement est testé avant d’être mis en ligne.

No code

• Les plateformes et produits configurables sont généralement utilisés dans leur état par défaut.
• Les capacités des plateformes à répondre de plus près aux besoins des entreprises sont peu appréciées.
• Il n’y a pas de révisions systématiques des capacités de la plateforme, de la feuille de route des fonctionnalités ou de l’application d’ensembles de fonctionnalités aux besoins commerciaux non traités.

Low code

• Les individus utilisent les compétences et les outils dont ils disposent, développant des solutions aux besoins locaux sans surveillance, examen ou reconnaissance de l’impact ou de l’interaction avec des besoins et activités stratégiques plus larges.
• Les solutions ne sont pas sauvegardées, documentées, rendues publiques ou résilientes.
• Les personnes qui créent des solutions utilisent des hacks et des approches inefficaces.
• Le code est souvent copié à partir du Web avec peu de compréhension de ses effets.
• Il n’ya pas de conception de sécurité ou de gouvernance ni d’évaluation d’impact.
• Les solutions ne sont pas sauvegardées dans le contrôle de source.
• Les solutions ne sont pas documentées.
• Il n’y a pas de soutien formel; le développeur citoyen peut ne pas être disponible pour fournir des correctifs, des améliorations ou des conseils.

Pro code

• Les développeurs ne connaissent pas la plateforme, alors ils écrivent du code au lieu d’utiliser des fonctionnalités natives. (Ceci est parfois appelé «la mentalité du code d’abord ».) Le code est écrit pour créer des composants qui réinventent la roue en raison d’un manque de compréhension de ce qui est déjà disponible avec la plateforme.
• Les TI sont insulaires et centrées sur l’interne. Il y a peu de soutien pour les besoins axés sur les services ou les processus.
• La fonction informatique n’a souvent aucune capacité de développement. De même, l’informatique peut être inflexible dans son approche, tous les développements sont traités comme des activités «au niveau de l’entreprise », ce qui rend de nombreux besoins de solutions non viables (trop coûteux, trop lents, attentes trop techniques des parties prenantes).
• Aucun outil de développement, tel que le contrôle de source et les méthodologies de tests, n’est utilisé.
• Des systèmes qui utilisent les services Microsoft 365 comme magasin de données sont développés, mais l’interface utilisateur est conservée en dehors de Microsoft 365.
• Les systèmes sont conçus et construits avec peu de réflexion, sur les services Microsoft 365 qui peuvent être collés ensemble pour fournir le système.

Gestion et gouvernance

Il n’y a pas de plateforme de développement, d’outil, de langage précisés au sein de l’entreprise. Il y’ a un manque d’appropriation du développement au nom de l’organisation. Aucune norme n’a été examinée ou publiée. Les interfaces utilisateur, l’image de marque, les normes de codage et la qualité, les plateformes et la sécurité sont laissés à la connaissance et aux compétences des membres du personnel.

Aussi, il n’y a pas de capture des besoins de développement et aucune visibilité des solutions (locales) qui ont été mises en place. Conséquemment, les équipes et les services commandent leurs propres développements à des sous-traitants et développeurs tiers, sans normes d’approvisionnement, revues de contrat ou accords de données et de sécurité. Aucun contrôle de source n’est utilisé pour contenir le référentiel de code. De plus, le développement est fréquemment effectué sans gestion des versions.

Les systèmes sont livrés sans documentation sur la façon dont ils sont administrés ou utilisés (par exemple, les guides de l’utilisateur et les guides de l’administrateur). Il n’y a pas d’environnements distincts, tels que Dev, QA, Production, donc des modifications sont apportées à Production/Live. (Avec de la compréhension, ce n’est peut-être pas une mauvaise chose; mais sans la comprendre ça l’est.)

Les systèmes qui fonctionnent dans l’organisation ne sont pas connus du service informatique. Ces systèmes fantômes sont découverts lorsque les choses tournent mal. De plus, il n’y a pas de processus DevOps qui utilise la solution construite par le développeur pour un déploiement contrôlé. Les systèmes sont construits sans penser à la façon dont le système sera pris en charge et maintenu.

Impacts

À ce niveau, vous pouvez vous attendre à ce qui suit:

• Systèmes et solutions d’apparence incohérente.
• L’organisation risque de casser les systèmes en raison d’une mauvaise configuration et/ou de problèmes de configuration.
• L’organisation risque de ne pas être en mesure de reconstruire une solution si elle est corrompue.
• De l’argent est gaspillé en développement lorsque d’autres approches utilisant un code bas ou sans code pourraient être utilisées pour obtenir des résultats similaires.

Niveau 200: Émergence de la discipline

Différents types de développement sont reconnus, mais il existe des tensions entre les parties de l’organisation qui adoptent des approches différentes. Le développement « fantôme » continue et est parfoisinterdit sans fournir d’alternatives. Le personnel est frustré par une mauvaise fonctionnalité, mais n’a aucun mécanisme pour demander ou mettre en œuvre des changements. Le développement est caractérisé par la construction pour vivre, bien qu’il puisse y avoir des tests et des contrôles au sein de cet environnement.

Ce niveau inclut:

No code

• Des solutions personnalisées sont développées à l’aide de technologies sans code; cependant, ceux-ci sont effectués avec une connaissance limitée des bonnes pratiques. Les solutions sont calquées sur les pratiques existantes, en utilisant des capacités superficielles et évitent généralement l’utilisation de fonctionnalités de plateforme plus approfondies.
• Les solutions ont tendance à être construites « à la volée », sans livrable ni spécification claire. Il n’y a pas de documentation sur le processus de conception et de construction.
• La façon d’utiliser le système est montrée aux utilisateurs et la documentation de base peut exister dans les documents de processus ou de procédures.
• Les mises à jour et les modifications sont ad hoc. Il n’y a pas d’équivalent du contrôle de source.
• Un petit nombre de personnes ont une expertise dans la configuration de la plateforme. La maintenance et le support des solutions dépendent de la disponibilité de ces personnes. Les « experts » maintiennent leurs connaissances sur les capacités de la plateforme, la feuille de route, etc. par intérêt personnel.

Low code

• Certains projets Power Platform ont des normes de couleurs cohérentes et utilisent des composants.
• Certaines solutions low code sont exportées vers le contrôle de source de base.
• Certaines solutions low code ont des environnements distincts pour le développement, les tests d’acceptation par les utilisateurs et la production.
• Il existe des conseils sur la décision d’utiliser des approches low-code et sur qui engager pour faire le développement, par exemple un développeur citoyen ou un partenaire externe.

Pro code

• Le contrôle de source est utilisé pour certains projets. Cependant, le système de contrôle des sources n’est pas standardisé dans l’ensemble de l’organisation. Il existe plusieurs référentiels et plusieurs systèmes de contrôle de source en cours d’utilisation.
• Les processus de déploiement sont ad hoc et peu fiables, nécessitant fréquemment une restauration.
• Les projets commencent à utiliser les normes de conception Microsoft 365 lors de la livraison des systèmes.
• Les approches de développement et les meilleures pratiques commencent à être comprises et sont adoptées par les membres de l’équipe de projet. Cependant, ils ne sont pas appliqués.

Gestion et gouvernance

Les développeurs ne connaissent pas la plateforme et les fonctionnalités natives, écrivant du code au mieux de leurs connaissances. Or, ceci crée souvent une dette technologique au sein de l’organisation.

À ce niveau, certains projets fournissent des systèmes avec des guides d’utilisation et des guides d’administration. La gestion des versions est prise en compte et la livraison d’un système et ses mises à niveau sont annoncées avant le déploiement. Cependant, il n’y a pas d’environnements de test dans lesquels le déploiement est publié en premier.

La communauté Microsoft 365 de l’organisation commence à partager des victoires et des histoires via des discussions ad hoc. Il n’y a pas de normes de développement partagées entre les projets. Les solutions sont souvent développées, notamment en utilisant no code et low code, sans avoir de plan de déploiement, de support et de gestion associée. L’évaluation des impacts sur les autres processus et solutions est complétement inexistant.

En complément, certains projets utilisent des plateformes Cloud telles que Microsoft Azure. Il y a encore peu de pratiques DevOps.

Impacts

À ce niveau, vous pouvez vous attendre à ce qui suit:

• Des budgets sont gaspillés en développement lorsque d’autres approches utilisant un low code ou un no code pourraient permettre d’obtenir des résultats similaires.
• Les approches de livraison sont incohérentes.
• La qualité des solutions développées est faible et ces solutions peinent à être adoptées.
• Il y a des problèmes lorsque les déploiements se font.

Niveau 300: Standardisation

Il y a une appréciation des limites de l’approche sans code, des approches low code et pro code. Les efforts pour introduire des normes, des conseils et une collaboration pour structurer la coexistence de différentes approches en fonction des différents besoins de l’entreprise sont valorisés. Des tentatives sont faites pour soumettre toutes les approches à une certaine forme de surveillance.

Le personnel est généralement satisfait des fonctionnalités, mais obtient systématiquement des résultats avec des lacunes, comme des incohérences et des mises à jour de fonctionnalités non critiques.

Ce niveau inclut:

No code

• Les étapes de création de solutions personnalisées sont capturées avec une certaine forme, la configuration est documentée et une description finale de la solution existe.
• Les développeurs connaissent et utilisent certaines méthodologies de développement.
• Les anciennes approches sont modifiées pour tirer parti des capacités de la plateforme et certains processus métier sont activement repensés pour apporter des améliorations en fonction de celles-ci.
• Les mises à jour et les améliorations doivent être planifiées et exécutées, mais les erreurs sont fréquentes.
• La documentation et la formation des utilisateurs sont adaptées au système, mais ont tendance à retarder les mises à jour. La documentation n’est toujours pas considérée comme faisant partie du livrable.
• Les solutions considérées comme importantes pour l’entreprise sont reconnues et un certain niveau de soutien a été mis en œuvre. Le personnel d’assistance est qualifié pour maintenir la plateforme et toutes les solutions, ce qui réduit le recours aux experts en solutions.
• Il y a une certaine consolidation des plateformes sans code; les feuilles de route et les mises à jour pour les plateformes standard sont activement suivies.
• La personnalisation des plateformes n’est effectuée qu’après examen de l’impact sur le personnel et les autres systèmes.

Low code

• La rigueur est mise en place autour de la documentation des solutions low code telles que les solutions construites sur la Power Platform.
• Les solutions low code sont sauvegardées en tant que solutions et stockées dans le contrôle de source.
• Les solutions low code disposent d’environnements distincts ou équivalents pour le développement, les tests d’acceptation par les utilisateurs et la production.

Pro code

• Le contrôle de source est utilisé pour la majorité des projets de développement.
• Les systèmes sont déployés principalement par le biais de processus manuels, mais complétés par des scripts pour certaines étapes.
• Les solutions disposent d’environnements distincts ou équivalents pour le développement, les tests d’acceptation des utilisateurs et la production.
• L’intégration continue et le déploiement continu peuvent être introduits parallèlement à d’autres approches.
• Les développeurs de Pro Code apprécient quand ne pas développer de solutions, en écrivant du code que lorsque cela est nécessaire et que cela peut faire la différence. Ils commencent à passer au Low Code et aux alternatives de configuration.

Gestion et gouvernance

Il y a une appréciation des limites de l’approche sans code, low code et pro code. Les besoins qui déclenchent une transition d’une approche à une autre sont identifiés et les options pour fournir des besoins étendus ou des fonctionnalités avec le code pro sont comprises. Ceci est souvent basé sur les besoins de l’entreprise avec un retour sur investissement mesurable.

Les bonnes pratiques sont comprises par un noyau d’experts et sont utilisées pour guider le développement de solutions. Il y a une reconnaissance des rôles du no code et du low code aux côtés des approches pro code. La règle des 80/20 est de plus en plus appliquée, en utilisant des fonctionnalités prêtes à l’emploi qui sont suffisamment bonnes pour fournir une utilité, utilisant souvent un processus pour s’adapter aux fonctionnalités prêtes à l’emploi (Out of the Box) plutôt que de recréer des solutions client. Le code personnalisé se concentre sur des solutions qui représentent la « sauce spéciale » de l’organisation, offrant le plus grand impact.

Il existe une compréhension de la dette technique et une stratégie est appliquée pour la réduire. Les systèmes fournis sont documentés et peuvent être gérés, entretenus et pris en charge.

L’équipe de développement pro et la communauté des développeurs citoyens comprennent comment créer des solutions sur la plateforme Microsoft 365. Les ressources de Microsoft et de la communauté sont utilisées pour améliorer leurs connaissances. Les développeurs pros et les développeurs citoyens se soutiennent mutuellement. Le développement à tous les niveaux commence à être soutenu par la formation et l’apprentissage pour améliorer les compétences. Il peut y avoir des certifications formelles pour soutenir et démontrer la compétence.

Des processus de gestion des versions sont mis en place, mais sont manuels. Des normes pour l’interface utilisateur (UI), les thèmes et le style sont créés et partagés. Des normes de conception sont publiées et permettent une approche cohérente pour l’interface utilisateur et le comportement fonctionnel. Les solutions existantes peuvent être mises à jour conformément à celles-ci.

Le contrôle des sources est standardisé et utilisé pour le développement pro code mais pas pour les approches low code. Les pratiques DevOps sont instaurés, bien que le code non pro ne soit souvent pas inclus dans ces normes.

La recherche utilisateurs est utilisée pour définir les exigences de certains systèmes; il y a une certaine tentative de standardiser les approches pour capturer et définir les exigences, telles que les histoires d’utilisateurs, etc.

Il y a émergence d’une communauté de champions M365. Cela prend en charge le besoin de processus de gouvernance, de documentation, de formation et de développement pour soutenir l’alignement des solutions sur le plan stratégique. Les membres de la communauté se réunissent périodiquement pour discuter des problèmes que les développeurs citoyens tentent de résoudre. Ces rencontres font partie de la thérapie technologique et de la formation continue, car Microsoft 365 est en constante évolution. Ces efforts sont appréciés et soutenus par la direction.

Des environnements distincts ou équivalents sont disponibles pour le développement, les tests et la production pour le code Pro et, souvent dans une mesure limitée, pour d’autres approches.

Impacts

À ce niveau, vous pouvez vous attendre à ce qui suit:

• Les partisans de différentes approches de développement s’apprécient mutuellement et discutent ouvertement de la manière de travailler ensemble. Des solutions émergentes combinent personnalisation, low code et pro code pour créer des solutions plus performantes et plus supportables.
• Des processus sont introduits pour encourager la gestion, la gouvernance et la normalisation, ce qui facilite le développement, l’adoption et le support.
• L’organisation dispose d’un forum pour partager les systèmes et les solutions qui ont été construits.
• Une version améliorée des systèmes à mesure que la structure, les processus et la rigueur du déploiement sont mis en place, simplifie le parc informatique et réduit la charge de support et les risques pour l’entreprise.

Niveau 400: Contrôle

Il existe des processus clairs et une aide à la décision pour la conception de solutions et la cartographie cohérente avec les besoins et les impacts de l’entreprise, englobant le continuum du code. Des normes fonctionnelles existent, etsont revues régilièrement ce qui permet d’éliminer activement les incohérences . Le portefeuille de solutions est bien compris et géré.

Le personnel est capable de travailler efficacement sur l’éventail des solutions et d’adopter facilement de nouvelles solutions en raison de leur cohérence et de leur interopérabilité. Les informations axées sur le support sont utilisées pour fournir des commentaires de manière proactive aux équipes de solutions afin de générer des améliorations. Les changements à venir sont communiqués clairement et bien à l’avance.

Ce niveau inclut:

No code

• Les configurations sont bien documentées et utilisées comme base de scripts et de modèles pour automatiser la création et les mises à jour du site. Ceux-ci sont bien gérés et maintenus via le contrôle de source.
• Les solutions sont développées et testées par rapport à un ensemble de directives de bonnes pratiques qui incluent une mise en page commune basée sur de bonnes approches d’interface utilisateur/expérience utilisateur (UI/UX), incorporant la marque et les normes de l’entreprise.
• Aucun développeur de code n’a une connaissance approfondie de la plateforme et n’est pris en charge pour maintenir et étendre ses connaissances. Ils savent également quand demander des conseils à des collègues ayant des compétences de développement complémentaires.
• La conception de la solution et l’architecture de l’information sont soigneusement étudiées; les contraintes sont comprises et des approches pour les éviter sont mises en œuvre, y compris l’inclusion ou le passage au développement low-code et pro-code.
• La sécurité, la gouvernance, la gestion et l’intégration sont considérées comme faisant partie de la conception de la solution et sont incluses dans les spécifications des solutions commerciales importantes. Ceux-ci sont donc testés dans le cadre du cycle de vie du développement.
• L’objectif, l’impact, le cycle de vie et l’échelle anticipés de la solution sont pris en compte, et les méthodologies de développement appropriées sont appliquées en conséquence.
• Les solutions sont examinées pour s’assurer qu’elles restent adaptées à leur objectif. Les changements sont gérés de manière appropriée.
• Les capacités changeantes de la plateforme sont appliquées de manière proactive aux solutions existantes.
• Les solutions commerciales importantes sont activement gérées et prises en charge.
• L’organisation investit dans une gamme complète de compétences de plateforme par rapport à une vaste stratégie de développement qui comprend des normes sans code, low code et pro-code et une approche intégrée de conception et de développement.

Low code

• La conception de la solution est soigneusement étudiée; les contraintes sont comprises et des approches pour les éviter ou les atténuer sont mises en œuvre.
• Les solutions low code utilisent le contrôle de source pour aider à gérer le processus de publication, dans la mesure du possible. Le processus de publication comprend des métriques qui peuvent être partagées au sein de l’organisation pour montrer les avantages des solutions low code.
• Les solutions low code utilisent des métriques d’outils tels qu’Application Insights pour mesurer l’adoption. Cela permet de prendre des décisions quant à savoir où concentrer les efforts sur les candidatures retenues et annuler ou retravailler les candidatures infructueuses. Ces mesures sont publiées et partagées au sein de l’organisation.
• Il existe un processus actif de test et d’évaluation et de rétroaction des utilisateurs, qui est utilisé pour établir une feuille de route pour les améliorations continues.
• Le cycle de vie des solutions est anticipé et les conceptions de solutions en tiennent compte.
• Des processus de conception centrés sur l’utilisateur standardisés garantissent que la solution répond aux besoins des utilisateurs et est conçue de manière appropriée pour le public.
• L’organisation continue d’investir dans la formation des développeurs citoyens et dans les outils pour les accompagner.
• L’organisation a investi dans l’octroi de licences pour s’assurer qu’il y a peu de frictions et que les décisions sont plus faciles à prendre lors de la création de solutions low code.
• Les composants de code Pro sont développés pour étendre les solutions low code, dans le cadre d’une approche «systèmes» bien comprise et holistique.
• Les méthodologies de code Pro sont adoptées chaque fois que cela est approprié.

Pro code

• Les solutions de code Pro utilisent le contrôle de source pour aider à gérer le processus de publication. Le processus de publication comprend des métriques qui sont partagées au sein de l’organisation pour montrer les avantages des solutions de code pro.
• Les solutions de code Pro utilisent des métriques d’outils tels qu’Application Insights pour montrer que de nombreux utilisateurs/applications les utilisent chaque jour. Cela permet de prendre des décisions sur le succès d’une demande. Une décision peut être prise quant aux applications sur lesquelles se concentrer. Ces mesures sont partagées au sein de l’organisation.
• Les solutions à faible utilisation sont régulièrement revues pour déterminer les améliorations utiles pour augmenter l’utilisation, le cas échéant.
• Les enseignements tirés du développement de solutions de code Pro sont partagés au sein de l’organisation.
• Les API sont développées de manière proactive pour permettre à No Code et Low Code d’accéder facilement à des sources de données, des fonctions et des automatisations commerciales sophistiquées.

Gestion et gouvernance

L’utilisation des applications est mesurée à l’aide d’outils tels qu’Application Insights. Les applications permettent de détecter les erreurs et les événements à l’aide d’outils tels qu’Application Insights.

L’intégration du développement se produit dans le continuum de code, le composant de pro code et les solutions sont conçus pour être consommés par des solutions à faible code et sans code. Les bibliothèques de ces « extensions » et les registres de leurs emplois sont publiés et maintenus.

Les statistiques sur le nombre de déploiements et de versions sont fournies par des outils de gestion des versions tels qu’Azure DevOps. Le contrôle de source est utilisé de manière efficace et cohérente, des tests automatisés sont en place. Des revues de code ont lieu pour garantir la qualité du code avant son introduction dans la base de code.

Les normes de conception sont appliquées de manière cohérente pour garantir que toutes les applications répondent aux attentes du personnel en matière d’interface utilisateur et de comportement. La recherche sur les utilisateurs est utilisée pour définir les exigences et fournir des mesures sur la convivialité, les améliorations et la productivité. Un comité directeur est créé pour développer et superviser les feuilles de route des solutions.

Impacts

À ce niveau, vous pouvez vous attendre à ce qui suit:

· Des applications et des systèmes de meilleure qualité sont fournis.

· Les normes de conception signifient que les utilisateurs peuvent utiliser l’application plus facilement, ce qui stimule l’adoption.

· Les applications répondent aux besoins de leurs utilisateurs grâce à l’approche de conception centrée sur l’utilisateur.

Niveau 500: Optimisation

Les décisions de conception sont régulièrement examinées pour en vérifier l’efficacité et l’apprentissage est appliqué pour affiner et optimiser continuellement les solutions. Des outils avancés sont utilisés pour mesurer l’expérience utilisateur et l’efficacité des solutions et améliorer la qualité de toutes les solutions. Ceux-ci sont également utilisés pour améliorer de manière proactive les normes et pour aider à façonner la formation des développeurs.

L’efficacité des solutions est évaluée en permanence via des mesures complètes, optimisant la productivité du personnel et garantir l’agilité face à l’évolution des besoins.

Ce niveau inclut:

No code

• Le référentiel de personnalisations et de modèles qui favorise la réutilisation des solutions est activement maintenu par l’entreprise et amélioré en fonction des technologies émergentes et des besoins de l’entreprise.
• Des solutions sophistiquées sans code sont facilement créées en les étendant avec des extensions low code et pro code qui fonctionnent de manière similaire à la plateforme sans code avec laquelle le personnel est familier.
• Les processus de gestion recherchent activement des opportunités de n’utiliser aucun code pour réduire les coûts et tirer parti du déploiement des fonctionnalités de la plateforme. L’impact de ces derniers est évalué sur une base continue et utilisé pour affiner les points de transition du code.

Low code

• Le référentiel de composants, modules et modèles qui favorise la réutilisation des solutions est activement maintenu par l’entreprise et amélioré en fonction des technologies émergentes et des besoins de l’entreprise.
• Les développeurs citoyens à faible code utilisent les crochets et les points d’extension construits par les développeurs de code pro et ne fournissent des améliorations à aucun code. Ceux-ci sont standardisés, avec des points d’intégration définis et des éléments de surveillance intégrés.
• La conformité aux normes est régulièrement évaluée et utilisée pour améliorer la qualité de la solution et du développeur.

Pro code

• Un flux de gestion des packages (tel qu’un flux interne NuGet ou NPM) est utilisé pour gérer et promouvoir la réutilisation des composants et des modèles.
• Le code Pro développe des points d’extension et des composants pour les développeurs citoyens sans code/low code à utiliser. Les exemples incluent des connecteurs personnalisés pour Power Platform ou des composants WebPart SPFx pour SharePoint et Teams.
• Les analyses sur l’utilisation des API pour les sources de données, les fonctions et les automatisations commerciales sont utilisées pour optimiser leurs utilisations et leurs performances.

Gestion et gouvernance

Le développement est géré de manière proactive tout au long du continuum du code; un équilibre dynamique est maintenu entre les différentes approches de code, évoluant pour tirer parti des changements dans le paysage de la technologie et des plateformes. Une veille active des technologies sources permet d’anticiper ces évolutions et de les intégrer dans les feuilles de route de développement.

Il existe un aperçu granulaire du portefeuille de solutions développées et du continuum de code, avec une compréhension des coûts d’origine, de la dette technologique, des coûts de support et des avantages. Ceux-ci sont intégrés aux métriques des utilisateurs. Ceux-ci sont utilisés pour orienter les stratégies de développement et les investissements.

Les métriques Application Insights sont utilisées pour mesurer l’adoption et sont partagées avec l’organisation. Les entonnoirs et les flux d’utilisateurs d’Application Insights sont utilisés pour voir comment les gens se comportent et utilisent les solutions. De plus, il y a une utilisation de tests A/B avec des métriques d’utilisabilité permettant à l’organisation de mesurer les meilleures approches.

Le contrôle de source fournit des tests robustes et hautement automatisés, des techniques d’intégration continue/livraison continue (CI/CD).

Un centre d’excellence et un comité de pilotage sont habilités à établir une feuille de route pour guider les points d’extensibilité construits avec le code pro pour les développeurs citoyens sans/Low code.

Les solutions sont conçues et publiées dans les magasins d’applications de l’organisation tels que SharePoint et Microsoft Teams.

Impacts

À ce niveau, vous pouvez vous attendre à ce qui suit:

• L’innovation au sein de l’organisation est activement soutenue par le déploiement rapide d’outils qui, à leur tour améliorent la maturité du nouveau produit, processus, etc.
• Une capacité à développer rapidement des solutions aux nouveaux besoins commerciaux à un rythme qui crée un avantage commercial, puis à les faire mûrir pour assurer la conformité et la prise en charge.
• Une main-d’œuvre plus productive avec des utilisateurs disposant des outils et des informations dont ils ont besoin quand ils en ont besoin.
• Une coordination transparente et invisible des différentes approches, conduisant à une adoption rapide du personnel et à une productivité améliorée grâce à la cohérence et à la standardisation.
• Une amélioration du retour sur investissement, car les solutions peuvent être réutilisées dans toute l’organisation.
• La promotion des meilleures pratiques et des leçons apprises afin que l’organisation ne souffre pas toujours du même problème.

Coût et bénéfices

Lorsque nous parlons des avantages de la personnalisation et du développement, il est plus facile de voir l’avantage et le retour sur investissement. Souvent, seul le gain de temps est utilisé pour quantifier le retour sur investissement. Lorsque le développement permet une nouvelle capacité au sein d’une entreprise, le chiffre d’affaires réalisé avec la nouvelle capacité peut générer un retour sur investissement jusqu’alors inconsidéré.

Voici des exemples d’avantages:

• Réduire le temps pour accomplir une tâche commune.
• Réduction du taux d’erreur lors de la copie manuelle d’informations d’un système à un autre.
• Permets d’obtenir des informations en extrayant des données d’un système et en les intégrant à un autre.
• Améliorer la productivité en permettant à l’entreprise de traiter plus pour moins.
• Améliorer la cohérence lors de la livraison de contenu aux clients.
• Permettre l’innovation au sein de l’organisation.
• Augmenter la satisfaction des employés (les employés se mettent au travail sur les tâches qui offrent plus de valeur que les ordinateurs ne peuvent en fournir).
• Diminuer le «délai de productivité» avec les nouveaux systèmes: coûts de formation réduits et temps de cycle plus rapides.
• Réduire le risque de l’entreprise.

Le coût de développement est cher et peut être contrôlé en ne se lançant que dans des projets qui en ont vraiment besoin et qui apportent de la valeur. De plus, déplacer le développement du code pro vers le low code, le cas échéant, contribuera à augmenter la valeur et l’innovation.

Conclusion

La personnalisation et le développement sont des ingrédients essentiels pour tirer le meilleur parti de Microsoft 365. Cependant, il est important que la personnalisation et le développement ne soient pas pris à la légère et qu’il y ait une compréhension de l’engagement pris. Lorsqu’ils sont effectués, un niveau de gestion et d’assistance est requis pour garantir que les solutions continuent de fonctionner à mesure que la plateforme évolue et que les problèmes imprévus puissent être résolus.

Les organisations doivent minimiser la personnalisation et le développement à moins qu’ils n’apportent une valeur essentielle à celle-ci. L’activité de personnalisation doit être mesurée et s’assurer qu’elle offre un retour sur investissement significatif.

Traditionnellement, les organisations ont traité les approches sans code et low code comme des « citoyens de seconde classe » par rapport au pro code. Dans les organisations en pleine maturité, cependant, chaque approche a un rôle à jouer, et le bon mélange peut créer une approche intégrée pour aborder les affaires à l’aide d’un continuum de code. À mesure que les silos et le « snobisme de code » sont réduits, les opportunités d’améliorer la normalisation, l’efficacité/l’assurance du développement et de fournir une rapidité ou une cadence accrue lors de la livraison de solutions à l’entreprise s’améliorent.

Lorsque le développement est effectué, il doit être réalisé de manière à réduire les risques pour l’organisation. Implémentez des référentiels de code source pour sauvegarder le code et assurez-vous que les développeurs sont productifs. C’est important, car trop souvent on entend des histoires où une organisation a une solution qui est utilisée, mais elle a perdu le code source.

La personnalisation et le développement ne peuvent contribuer au maximum à l’organisation que s’ils s’inscrivent dans une vision globale de la maturité organisationnelle qui inclut également les autres compétences. En fin de compte, la technologie est un ensemble d’outils, mais les gens peuvent utiliser la technologie pour atteindre leurs objectifs communs. La technologie sans se concentrer sur les aspects humains réussit rarement.

Pour connaître la raison d’être et les fondements des modèles de maturité Microsoft 365, suivez la série Maturité M365. Cet article est basé sur «Maturity Model for Microsoft 365 — Management of Content Competency».