Guichet Unique ou Foutoir Unique, c'est selon !

Je ne vais pas vous parler du report de la mise en place du Guichet Unique au 1er juillet, mais de ce que ce fiasco m'inspire quant à la mise en œuvre d'un projet informatique complexe.

Il est généralement préférable de décomposer le projet en plusieurs phases ou itérations plutôt que de tout proposer dans la première version.

Cette approche est connue sous le nom de développement itératif ou agile.

Le développement itératif permet de diviser le projet en plusieurs parties plus petites et plus faciles à gérer. Cela permet de mieux maîtriser les risques, de mieux répartir la charge de travail et de fournir des résultats plus rapidement.

De plus, en utilisant une approche itérative, il est possible de recueillir des commentaires des utilisateurs plus tôt dans le processus de développement. Cela permet d'identifier rapidement les problèmes et de les résoudre avant qu'ils ne deviennent trop importants. Cette approche peut également permettre de mieux s'adapter aux évolutions et aux changements de besoins des utilisateurs.

Comment pourrions-nous décomposer l'exemple du projet Guichet Unique ?

Décomposer un projet complexe peut être un processus délicat et peut varier selon la nature du projet, le contexte et les parties prenantes. Toutefois, voici quelques étapes possibles pour décomposer et prioriser les fonctionnalités d'un projet complexe qui s'adresserait à toutes les formes juridiques de création d'entreprise en France :

1. Identifier les principales formes juridiques de création d'entreprise en France, telles que la SAS, la SARL, l'EURL, la SASU, etc.
2. Déterminer les fonctionnalités de base nécessaires pour chaque forme juridique.
3. Hiérarchiser les fonctionnalités en fonction de leur importance pour chaque forme juridique.
4. Évaluer les ressources nécessaires pour chaque fonctionnalité, tels que le temps, les compétences et les coûts. Cela permettra de déterminer si certaines fonctionnalités doivent être reportées ou abandonnées en raison de contraintes de ressources.
5. Définir les itérations ou les phases du projet en fonction de la priorisation des fonctionnalités. Par exemple, la première itération pourrait inclure les fonctionnalités de base nécessaires pour la création d'entreprise, tandis que les itérations suivantes pourraient ajouter des fonctionnalités plus avancées en fonction des retours des utilisateurs et des ressources disponibles.

Il est important de garder à l'esprit que la priorisation des fonctionnalités est un processus continu et peut être révisée en fonction des évolutions du projet, des besoins des utilisateurs et des contraintes de ressources.

Comment pourrions-nous commencer ?

Commencer par les formes juridiques en constitution les moins utilisées en France, comme les Sociétés Anonymes (SA), peut être une stratégie viable dans certains cas, mais cela dépend des objectifs du projet, des ressources disponibles et de la demande du marché.

D'un côté, commencer par les formes juridiques moins utilisées peut permettre de tester la faisabilité et la viabilité du projet avec un groupe plus restreint d'utilisateurs. Cela peut également permettre de mieux maîtriser les risques et d'affiner les processus de développement avant d'attaquer les formes juridiques les plus courantes.

D'un autre côté, commencer par les formes juridiques moins utilisées peut également signifier que les fonctionnalités les plus demandées par la majorité des utilisateurs seront reportées, ce qui peut entraîner une perte de marché et un manque d'adoption de la solution.

En somme, la décision de commencer par les formes juridiques en constitution les moins utilisées dépend des objectifs du projet, des ressources disponibles et de la demande du marché. Il est important de prendre en compte ces facteurs et d'évaluer les risques et les avantages potentiels avant de décider de l'approche à suivre.

Mais, traiter toutes les constitutions de forme juridique en même temps peut être risqué et complexe :-( , surtout si le guichet unique est un élément clé. Il peut être préférable de suivre une approche plus progressive, en se concentrant sur un nombre limité de formes juridiques dans un premier temps, avant d'étendre progressivement la solution à d'autres formes juridiques.

Pour décider quelles formes juridiques traiter en priorité, il peut être utile de prendre en compte plusieurs facteurs, tels que :

• La popularité de la forme juridique : si une forme juridique est utilisée par un grand nombre d'entreprises, il peut être judicieux de la traiter en priorité pour maximiser l'impact de la solution.
• Les spécificités de la forme juridique : certaines formes juridiques peuvent avoir des particularités ou des exigences réglementaires spécifiques qui nécessitent une attention particulière.
• Les ressources disponibles : si les ressources de développement sont limitées, il peut être préférable de se concentrer sur un petit nombre de formes juridiques pour commencer.

En suivant une approche progressive, vous pourrez tester la solution sur un nombre limité de formes juridiques avant de l'étendre à d'autres formes juridiques. Cela peut vous aider à identifier les problèmes éventuels et à apporter des améliorations avant de lancer la solution sur l'ensemble du marché.

Exemples de projets complexes qui ont connu des échecs

Il y a plusieurs exemples de projets complexes qui ont connu des échecs en raison d'une approche inadéquate de la planification et de la gestion du projet.

Voici quelques exemples à l'international :

• Le projet de lancement du système de paye Phénix pour le gouvernement canadien en 2016, qui avait pour objectif de moderniser le système de paye des employés fédéraux. Le projet avait été conçu pour être déployé simultanément pour tous les employés fédéraux, mais il a rapidement été confronté à des problèmes de compatibilité avec les systèmes existants, de formation insuffisante des utilisateurs et de bugs logiciels. Le projet a été lancé malgré ces problèmes et a causé des retards de paye, des erreurs et des frustrations pour des milliers d'employés, qui ont dû attendre des mois pour recevoir leur salaire.
• Le projet de lancement du système de réservation de billets pour la compagnie aérienne américaine United Airlines en 2012, qui avait pour objectif de moderniser et d'unifier les systèmes de réservation existants de la compagnie. Le projet avait été planifié pour être déployé simultanément pour toutes les régions de la compagnie, mais a été confronté à des problèmes techniques majeurs dès son lancement, notamment des erreurs de réservation, des retards de vol et des annulations de vol. La compagnie a dû finalement interrompre le projet et revenir aux systèmes de réservation existants.
• Le projet de lancement du site web de l'assurance maladie américaine en 2013, qui avait pour objectif de permettre aux Américains de souscrire une assurance maladie en ligne. Le projet avait été conçu pour être déployé simultanément dans tout le pays, mais a rapidement été confronté à des problèmes de performances, de sécurité et de compatibilité avec les systèmes existants. Le lancement du site a été un fiasco, avec des retards, des pannes, des messages d'erreur et des frustrations pour les utilisateurs.

En France, il y a également eu des exemples de projets complexes qui ont échoué en raison d'une mauvaise gestion ou planification.

En voici quelques-uns :

• Le projet de lancement de l'application mobile de la SNCF en 2017, qui avait pour objectif de permettre aux voyageurs de réserver et de payer leur billet de train via leur smartphone. Le projet avait été conçu pour être déployé simultanément sur l'ensemble du réseau de la SNCF, mais a été confronté à des problèmes de performances, de sécurité et de compatibilité avec les systèmes existants. Le lancement de l'application a été retardé et la SNCF a dû faire face à des critiques pour les problèmes rencontrés.
• Le projet de modernisation du système de paye de l'armée française en 2015 (Louvois), qui avait pour objectif de remplacer les systèmes de paye existants par un système unique et modernisé. Le projet avait été conçu pour être déployé simultanément pour tous les militaires français, mais a été confronté à des problèmes de compatibilité avec les systèmes existants, de formation insuffisante des utilisateurs et de bugs logiciels. Le projet a été lancé malgré ces problèmes et a causé des retards de paye, des erreurs et des frustrations pour des milliers de militaires, qui ont dû attendre des mois pour recevoir leur solde.
• Le projet de lancement du système d'information de Pôle Emploi en 2010, qui avait pour objectif de moderniser le système de gestion des demandeurs d'emploi en France. Le projet avait été conçu pour être déployé simultanément dans tous les centres Pôle Emploi en France, mais a été confronté à des problèmes de performances, de sécurité et de compatibilité avec les systèmes existants. Le lancement du système a été retardé et a causé des retards dans le traitement des demandes d'emploi.

Allons-nous ajouter à cette liste le projet du Guichet Unique ?

Ces exemples montrent que la gestion de projets complexes peut être difficile, même pour des organisations importantes et expérimentées.

La planification rigoureuse et l'approche progressive peuvent aider à minimiser les risques et à éviter les échecs coûteux.

En somme, il est généralement préférable de décomposer un projet informatique complexe en plusieurs phases ou itérations plutôt que de tout proposer dans la première version. Cette approche permet de mieux gérer les risques, de mieux répartir la charge de travail et de fournir des résultats plus rapidement, tout en s'adaptant aux évolutions et aux changements de besoins des utilisateurs.

Expert dans la mise en place de solutions numériques, je vous propose un accompagnement adapté à vos besoins.

Rencontrons-nous pendant 15 min en ligne pour échanger sur votre projet digital !

#digital #transformationnumérique #transformationdigitale #nocode #lowcode  #HygièneNumérique #ProtectionDesDonnees #Agile