Projets SIG : série « Considérations sur le triage » : partie 6

Conclusion de cette série en six parties sur un cadre à six piliers pour aider à naviguer et à hiérarchiser les projets SIG. La sixième partie traite de la nécessité de comprendre la manière de gérer un projet ou une application. À la fin de la série, vous disposerez d’un guide pratique pour vous aider à trier les projets, ce qui rendra le processus plus fluide et plus facile à gérer. Cette partie comprend un aide-mémoire qui vous sera utile.

Comme indiqué dans les parties 1, 2, 3, 4, et 5, il est important de noter que ce cadre se fonde sur mes expériences en tant que conseiller et spécialiste en solutions technologiques. Il s’appuie sur une expérience personnelle sur les projets et l’évaluation des risques connexes et peut ne pas correspondre totalement à la position de votre organisation en matière de technologie, de formation et de capacité, de flux de travaux ou de sécurité et de protection de la vie privée.

Les six piliers du triage de projets SIG

Le cadre de triage comprend six piliers

Pour revenir à mes billets précédents, ce cadre prend en compte six piliers pour le triage des demandes de projets SIG : 

• Rendement de l’investissement : Le projet a-t-il un rendement de l’investissement tangible?
• Risque : Quels sont les risques associés au projet?
• Intervenants : Quelles sont les capacités requises pour le projet et son maintien tout au long de son cycle de vie typique?
• Technologie : Quels sont les éléments de technologie ou d’équipement nécessaires à la réussite du projet?
• Données : Les données impliquées dans le projet sont-elles exactes, sécurisées, accessibles et opportunes?
• Application et projet : Quels sont les livrables, les résultats et les mesures de réussite du projet? 

Ce billet de blogue traite de la compréhension des applications et des projets.

Comprendre les applications et les projets

Comprendre les applications et les projets

Bienvenue dans la dernière partie de ma série sur les considérations pour trier les projets. Ce billet de blogue traite des considérations d’un projet dans son ensemble. Il présente également un exemple de produit livrable; une application web. À mesure que nous explorerons les considérations abordées, nous espérons que vous comprendrez comment les appliquer à d’autres projets, comme une migration, une mise à niveau ou un remplacement. 

Comprendre nos histoires d’utilisateurs, nos cas d’utilisation et nos flux de travaux

Comprendre les histoires d’utilisateurs

Dans le cadre d’un projet d’envergure comportant plusieurs intervenants ou des flux de travaux complexes, il est essentiel de comprendre les histoires d’utilisateurs. Une proposition de projet qui prend bien en compte ces histoires a plus de chances de réussir puisque les exigences techniques et non techniques y ont été entièrement intégrées.

Toutefois, la proposition ne peut pas présenter tous les scénarios et flux de travaux possibles. C’est pourquoi une approche agile et itérative du développement est de mise; elle permet une certaine flexibilité dans la conception sans perdre de vue la fonctionnalité principale.

Par conséquent, les propositions de projet qui ne tiennent pas compte des idées des utilisateurs ont moins de chances de réussir. Si les utilisateurs actuels ne sont pas pris en compte dans le processus, le projet reflétera le point de vue d’un non-utilisateur. En pareil cas, il sera impossible de comprendre les véritables besoins des utilisateurs. Ainsi, l’adoption du produit se heurtera certainement à des résistances.

Comprendre la réutilisation

Comprendre la réutilisation

Lors de l’évaluation du projet, il est important de se demander si celui-ci génèrera des composants technologiques ou des compétences qui seront réutilisables, recyclables ou valorisables ailleurs dans l’organisation. Heureusement, la plupart des projets donnent des résultats qui peuvent être réutilisés. Toutefois, il faut faire preuve de prudence avec les projets qui nécessitent des efforts importants ainsi que des compétences et des technologies spécialisées pour accomplir des tâches ponctuelles. Prenons un projet qui demande d’embaucher temporairement des consultants spécialisés pour intégrer une application sans API. Celui-ci peut présenter un risque plus élevé parce qu’une grande partie des connaissances et de la propriété intellectuelle est susceptible de « passer sous le radar » pendant le transfert de connaissances.

Pour atténuer ces risques, nous devrions donner la priorité à l’utilisation de modèles de solutions et de configurations prêtes à l’emploi, dans la mesure du possible. Cette approche permettant une certaine personnalisation s’aligne sur un cadre de développement commun et assure un meilleur partage de la base de code.

Comprendre l’approche de développement du projet et de l’application

Comprendre l’approche de développement du projet et de l’application

Les méthodologies Agile et DevOps sont particulièrement bénéfiques pour les projets SIG, notamment les mises en œuvre centrées sur le nuage, les mises à niveau d’applications cartographiques SIG et les nouvelles applications cartographiques frontales. L’approche itérative Agile permet une réévaluation et une adaptation continues, ce qui est crucial pour gérer les exigences complexes et évolutives des projets SIG. Par exemple, dans le cadre d’une mise en œuvre centrée sur le nuage, l’approche Agile permet à l’équipe de déployer et de tester les composants de manière incrémentielle, en s’assurant que chaque partie fonctionne correctement avant de passer à la suivante. Cela réduit le risque de défaillance de grande envergure et permet des ajustements rapides en fonction des commentaires des utilisateurs.

L’approche DevOps bonifie davantage la méthodologie Agile en intégrant le développement et les opérations ainsi qu’en assurant une collaboration transparente et des flux de travaux efficaces. Les systèmes de contrôle de version tels que Git sont essentiels pour le suivi des modifications et la gestion de plusieurs développeurs travaillant sur le même projet, une situation courante en contexte de mise à jour d’applications de cartographie SIG. Ensemble, les approches Agile et DevOps offrent un cadre solide qui améliore la flexibilité, réduit les risques et garantit des résultats de haute qualité pour les projets SIG.

En revanche, l’approche en cascade est plus risquée en raison de son processus linéaire et séquentiel, dans lequel chaque phase doit être achevée avant de passer à la suivante. Il existe un risque accru de découvrir des problèmes importants à un stade tardif du projet, ce qui rend leur résolution plus coûteuse et plus longue.

Comprendre la matrice de gestion des responsabilités et du cycle de vie (RACI)

Comprendre la matrice de gestion des responsabilités et du cycle de vie

Il s’agit d’un sujet particulièrement important qui demande à ce qu’on s’y attarde. Dans la plupart des cadres du cycle de développement logiciel, il est essentiel de définir clairement les rôles et les responsabilités de l’équipe de projet, de l’équipe de soutien, des propriétaires et des utilisateurs finaux. En clarifiant les choses dès le début de la phase de proposition du projet, on évite la confusion et on s’assure que tous les membres de l’équipe comprennent leur rôle. Cette prise de conscience favorise une communication efficace au sein des équipes et auprès des intervenants externes, en plus d’assurer que les bonnes personnes interviennent dans la prise de décision au moment opportun.

En définissant clairement les rôles de l’équipe, nous pouvons attribuer les responsabilités et affecter les ressources de manière efficace, et ainsi réduire les risques du projet. La mise en œuvre d’une matrice RACI dès le début d’une proposition établit une base solide pour la gestion du projet et aide à budgétiser les ressources nécessaires.

Une matrice RACI (responsabilité, autorité, consultation, information) est un tableau qui définit les droits de décision des équipes participant au projet. Cliquez sur le lien pour savoir comment mon collègue Matt Lewin décrit l’utilisation du modèle RACI dans le processus de mise en œuvre de la gouvernance. Bien que la matrice RACI s’applique au niveau macro (organisationnel), nous pouvons l’adapter au niveau micro (projet). Le fait de mettre en œuvre une stratégie géospatiale avec une structure de gouvernance organisationnelle bien définie favorise un environnement dans lequel ces cadres peuvent être appliqués au niveau du projet.

Par exemple, la matrice RACI suivante décrit les rôles dans le cadre d’un projet de migration d’ArcGIS Enterprise à partir d’un déploiement sur place vers l’environnement Azure Cloud :

Comprendre le modèle RACI

À toutes les phases du projet de migration, le rôle et les responsabilités de chacune des équipes sont clairement définis. Ces informations aident l’équipe d’évaluation du projet à déterminer les échéances budgétaires et l’affectation des ressources.

Comprendre l’affectation de ressources dans le cycle de vie

Comprendre l’affectation de ressources dans le cycle de vie

En plus de comprendre la matrice RACI, nous devrions avoir une idée du niveau d’effort (ressources et temps) qui sera nécessaire pour chacune des phases. C’est probablement à ce stade que je poserais de nombreuses questions sur les membres qui composeront l’équipe de base pour chaque phase. 

Comprendre la nécessité du délai de mise en service

Comprendre la nécessité du délai de mise en service

Il est avantageux de définir clairement la date de mise en service d’un projet. Cela dit, si ces délais sont serrés, sans ressources ni budget adéquats, il peut devenir difficile de les respecter. Les projets dont les échéances sont bien définies et dont les ressources sont entièrement budgétées ont tendance à présenter moins de risques que les projets demandés « pour hier ». Ces projets urgents découlent souvent de besoins opérationnels immédiats et imprévus ou de pressions externes.

Par exemple, si une région connaît des incendies de forêt soudains et extrêmes, l’organisation peut ne pas avoir la « mémoire musculaire » nécessaire pour répondre au besoin de diffusion de l’information au grand public. Ces projets concernent des informations vitales et peuvent s’avérer très risqués si des applications sont développées à la volée. C’est un peu comme si on construisait un avion en plein vol. Toutefois, ce risque peut être atténué grâce à des cadres de projet agiles ou itératifs, notamment le recours à un produit minimum viable (PMV) et l’ajout de fonctionnalités en sprints. Les modèles de solutions ArcGIS et les créateurs d’applications sont particulièrement bien placés pour ce processus. Par ailleurs, j’ai aidé de nombreux clients en situation d’urgence à créer des applications destinées au public afin qu’ils puissent prendre des décisions cruciales en temps voulu.

Les projets demandés « pour demain » présentent un risque moyen. Généralement, ils n’ont pas atteint un stade critique pour l’entreprise et souvent, on s’y attarde lorsqu’il est trop tard. Pensons à un projet de mise à niveau d’ArcGIS Enterprise vers la dernière version qui est reporté à plusieurs reprises pour diverses raisons, jusqu’à ce que l’organisation soit la cible d’une attaque de vulnérabilité qui compromet son SIG. Il est toujours bon de tenir à jour les systèmes géospatiaux de l’entreprise et d’apporter les correctifs pour éviter les vulnérabilités.

Comprendre les exigences en matière d’accessibilité

Comprendre l’accessibilité

Dans de nombreuses organisations, en particulier au gouvernement, améliorer la mise en œuvre de technologies habilitantes pour répondre aux exigences d’accessibilité est un besoin reconnu. Les applications et les projets qui respectent les directives WCAG AA sont conformes à ces objectifs. Cependant, les projets qui s’écartent des directives WCAG AA, comme ceux qui ne satisfont que les directives WCAG A, qui visent les WCAG AAA ou, pire, qui ne sont pas conformes, présentent des risques importants.

Raisons de l’augmentation du risque :

Conformité juridique et réglementaire : Le non-respect des normes WCAG AA peut entraîner des problèmes d’ordre juridique, car de nombreuses lois sur l’accessibilité renvoient à ces directives. Le non-respect des directives peut entraîner des poursuites judiciaires, des amendes et d’autres mesures judiciaires.

Accessibilité et expérience des utilisateurs : Les directives WCAG AA garantissent que le contenu web est accessible à un large éventail d’utilisateurs, y compris les personnes handicapées. Les projets qui ne respectent que les directives WCAG A peuvent ne pas tenir compte des obstacles critiques à l’accessibilité, ce qui rend le contenu difficile, voire impossible, à parcourir pour certains utilisateurs. L’idéal est de viser la norme WCAG AAA, mais parvenir à une telle conformité sur l’ensemble d’un site peut s’avérer complexe, et ce n’est peut-être pas tout le contenu qui s’y prête.

Réputation et confiance : Les organisations qui ne respectent pas les normes d’accessibilité risquent de nuire à leur réputation. Les utilisateurs s’attendent à des expériences numériques accessibles et inclusives; la non-conformité est susceptible d’induire une perception négative et une perte de confiance de la part du public.

Incidences financières : Le fait de résoudre des problèmes d’accessibilité après l’achèvement d’un projet peut s’avérer coûteux. Il est plus efficace et plus rentable d’intégrer la conformité aux directives WCAG AA dès le départ plutôt que d’adapter les solutions après-coup.

Inclusion et responsabilité sociale : Le respect des directives WCAG AA témoigne d’un engagement en faveur de l’inclusion et de la responsabilité sociale. Cela garantit que le contenu numérique est accessible à tous les utilisateurs, quelles que soient leurs capacités, et promeut l’égalité et la diversité.

Esri intègre les principes de conception inclusive tout au long de la création de ses principaux logiciels, sites web et systèmes de conception. La mission poursuivie transparaît dans la facilité d’utilisation des produits et des solutions. L’engagement d’Esri en faveur de l’accessibilité est décrit ici, y compris l’accès à la vérification et aux rapports de conformité.

Comprendre le volume d’utilisateurs et la fréquence d’utilisation

Comprendre le volume d’utilisateurs et la fréquence d’utilisation

À l’évidence, les projets ou les applications ayant une large base d’utilisateurs sont généralement moins risqués du point de vue de la valeur commerciale. Toutefois, ils peuvent présenter un risque élevé dans d’autres domaines. Par exemple, la nécessité d’une haute disponibilité des services pour un SIG d’entreprise entraîne un risque élevé sur le plan de la fiabilité et de la disponibilité. Dans le cadre d’un projet de grande envergure, une application utilisée par de nombreuses personnes dans une entreprise peut s’avérer un appui de taille à la mission de l’organisation, qui elle est centrée sur l’employé. En fournissant une technologie complète, une telle application permet au personnel d’accomplir ses tâches de manière efficace et efficiente, ce qui en fait une occasion peu risquée d’un point de vue global d’apporter une valeur ajoutée à l’entreprise.

En revanche, un projet ponctuel qui ne concerne que quelques utilisateurs peut être plus risqué, surtout si sa mise en œuvre et son maintien nécessitent des ressources importantes. Il est possible que ces projets n’offrent pas le même rendement de l’investissement et détournent les ressources au détriment d’initiatives plus importantes.

Prenons l’exemple suivant : une proposition de projet vise à développer sur mesure une application permettant d’automatiser le processus annuel de déclaration obligatoire des immobilisations corporelles du CCSP. Si la proposition tenait compte de tous les risques potentiels, comme le temps, les ressources et l’absence d’intégration, il serait possible d’envisager des solutions commerciales prêtes à l’emploi telles que Cityworks qui permettent aux utilisateurs de générer eux-mêmes les rapports. Si les demandes de solutions ponctuelles et d’applications personnalisées sont nombreuses, il peut être utile de les réévaluer dans un contexte élargi afin de déterminer la viabilité d’un projet de mise en œuvre, à l’échelle de l’organisation, d’un système de gestion des actifs géospatiaux qui répond aux défis que ces solutions ponctuelles tentent de résoudre.

Comprendre la modalité d’accès

Comprendre la modalité d’accès

Les applications basées sur navigateur web sont généralement moins risquées, car elles sont accessibles à partir de n’importe quel appareil équipé d’un navigateur web. Celles-ci sont donc très accessibles et compatibles, réduisent les risques de problèmes de compatibilité et permettent d’atteindre un public plus vaste. De plus, les mises à jour sont faciles à effectuer puisqu’elles sont centralisées, de sorte que tout le monde reçoit aisément la dernière version. Ces applications sont également moins coûteuses à développer, car elles ne demandent pas de créer différentes versions pour chaque système d’exploitation.

Les applications web exclusivement mobiles présentent un peu plus de risques. Elles doivent tenir compte de la taille de l’écran et de la bande passante. Qui plus est, les navigateurs mobiles peuvent avoir du mal à effectuer des tâches complexes. Cela dit, l’utilisation d’outils tels que les modèles ArcGIS peut aider à relever ces défis.

Les applications natives exclusivement mobiles dépendent de systèmes d’exploitation spécifiques comme iOS et Android, ce qui peut limiter leur base d’utilisateurs et nécessiter un développement distinct pour chacune des plateformes. En plus de présenter des problèmes de sécurité uniques, elles doivent être optimisées pour différents appareils, ce qui complique le développement et les tests.

Les applications téléchargées à partir de boutiques d’applications comportent leurs propres risques. Même si les boutiques d’applications appliquent des règles strictes, il est toujours possible que des applications malveillantes parviennent à s’y infiltrer. Les utilisateurs doivent également mettre à jour manuellement les applications, ce qui peut retarder l’exécution de correctifs de sécurité importants. De plus, le fait que les boutiques d’applications contrôlent la distribution peut limiter la façon dont les développeurs gèrent les mises à jour.

Les applications installées sur place présentent le risque le plus élevé. Elles nécessitent des bibliothèques, du matériel et des installations manuelles spécifiques. Leur utilisation doit être certifiée sécuritaire pour les machines des utilisateurs, et concevoir une interface utilisateur conviviale peut nécessiter beaucoup de ressources. La mise à l’échelle de ces applications peut également s’avérer difficile et coûteuse.

Comprendre la stratégie de communication du projet

Comprendre la stratégie de communication du projet

En tant que coordinateur de projets SIG, vous ne pensez pas systématiquement à la manière dont un projet ou une application sera communiqué aux autres. Cette responsabilité peut incomber à une autre personne dans la matrice RACI. Cependant, il est important de savoir à qui sera présenté l’application ou le projet.

Cela est particulièrement vrai pour les projets qui utilisent une approche itérative ou agile. La gestion des attentes des clients et des utilisateurs tout au long du projet peut contribuer à réduire le risque de non-respect des exigences.

Je considère que les stratégies de communication pour les applications destinées au public présentent le risque le plus élevé. Le message doit s’aligner sur la mission de l’entreprise, la stratégie SIG globale, les attentes du public ainsi que les exigences techniques et non techniques du projet. Une fois la communication établie, il est difficile de se rétracter en cas d’erreur. Ainsi, lors de l’évaluation d’une proposition de projet, il convient de se demander à qui est destinée la communication et à quel moment elle sera envoyée.

En outre, les projets qui nécessitent davantage de technoévangélisme présentent un risque plus élevé. Ces projets doivent souvent faire l’objet d’une promotion et d’un appui important pour que les utilisateurs y adhèrent. Cela peut s’avérer difficile, car il faut convaincre les intervenants de la valeur du projet et veiller à la cohérence des messages sur les différents canaux. Si ces efforts s’avèrent inefficaces, le projet risque de ne pas avoir l’effet escompté, ce qui entraînera un gaspillage de ressources et une atteinte potentielle à la réputation. Il est donc essentiel de planifier et d’exécuter soigneusement les stratégies de communication afin d’atténuer les risques et d’assurer la réussite de tels projets.

Et nous voici à la fin

Une stratégie géospatiale bien définie est essentielle pour trier efficacement les projets. Elle permet d’établir un cadre pour évaluer les projets potentiels, en veillant à ce qu’ils apportent une valeur commerciale significative et durable grâce à l’intelligence de localisation. Cette stratégie oriente l’évaluation des projets aux niveaux opérationnel et tactique. Même si votre organisation n’a pas de vision géospatiale officielle, il est important de s’assurer que les projets proposés s’alignent sur la stratégie informatique globale et la vision de l’entreprise.

Comprendre l’alignement

Merci d’avoir suivi ma série sur le cadre à six piliers du triage des demandes de projet! Beaucoup d’entre vous m’ont demandé comment choisir les projets à exécuter tout en gérant les tâches quotidiennes. Bien que je n’aie pas couvert tous les cas de figure, j’espère que ces billets vous ont apporté des informations précieuses.

Si vous les avez trouvés utiles, j’aimerais que vous me fassiez part de vos commentaires. N’hésitez pas à me contacter sur LinkedIn. Si vous souhaitez en savoir plus sur la façon dont une stratégie géospatiale peut aider votre organisation à réussir grâce à l’intelligence de localisation, je peux vous aider à vous connecter.

En prime, j’ai ajouté une liste de vérification d’une page qui résume les six piliers dont nous avons discuté. Cette liste de vérification, ainsi que les billets de blogue, devrait vous aider à hiérarchiser efficacement vos projets.

Liste de vérification pour le triage des projets V1.0

Ce billet a été écrit en anglais par Nathan Enge et peut être consulté ici.