Types d’implémentation des systèmes en ligne de gestion des marchés publics : options pour l’Afrique ÉQUIPE PROJET : Blandine Wu Chebili - World Bank Group Hunt La Cascia - World Bank Group François Collineau - CKS Consulting Arnaud Salomon - CKS Consulting Baptiste Calvet - CKS Consulting Yoann Moreau - SQUAD 2 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE © 2021 Banque internationale pour la reconstruction et le développement / Banque mondiale 1818 H Street NW, Washington DC 20433 Téléphone : 202-473-1000 ; Internet : www.worldbank.org Certains droits sont réservés. Le présent ouvrage est un produit de l’équipe de la Banque mondiale enrichi de contributions externes. Les constats, interprétations et conclusions qui y figurent ne représentent pas nécessairement les points de vue de La Banque mondiale, des Administrateurs de son Conseil ou des gouvernements qu’ils représentent. La Banque mondiale ne garantit pas l’exactitude des informations qui figurent dans le présent ouvrage. Les frontières, les couleurs Les frontières, les couleurs, les dénominations et autres informations figurant sur les cartes de cet ouvrage n’impliquent aucun jugement de la part de la Banque mondiale en ce qui concerne le contenu de ces cartes. jugement de la part de la Banque mondiale concernant le statut légal d’un territoire ou l’approbation ou l’acceptation de ces frontières. Aucun élément du présent ouvrage ne constitue ou n’est considéré comme une limitation ou une renonciation aux privilèges et immunités de La Banque mondiale, qui sont tous spécifiquement réservés. Droits et autorisations : Le présent ouvrage est disponible sous la licence Creative Commons Attribution 4.0 IGO (CC BY 4.0 IGO) https://creativecommons. org/licenses/by/4.0/. En vertu de la licence Creative Commons Attribution, vous êtes libre de copier, distribuer, transmettre et adapter cet ouvrage, y compris à des fins commerciales, dans les conditions suivantes : Attribution - veuillez citer l’œuvre comme suit : World Bank. (2021). Teach ECE (First Edition). Washington, DC: The World Bank. Licence : Creative Commons Attribution CC BY 4.0 IGO. Traductions - Si vous créez une traduction du présent ouvrage, veuillez ajouter la clause de non- responsabilité suivante, ainsi que la mention de la source : Cette traduction n’a pas été créée par La Banque mondiale et ne doit pas être considérée comme une traduction officielle de La Banque mondiale. La Banque mondiale n’est pas responsable du contenu ou des erreurs de cette traduction. Adaptations - Si vous créez une adaptation du présent ouvrage, veuillez ajouter la clause de non- responsabilité suivante, ainsi que la mention de la source : Ceci est une adaptation d’une œuvre originale de la Banque mondiale. Les points de vue et opinions exprimés dans l’adaptation sont de la seule responsabilité de l’auteur ou des auteurs de l’adaptation et ne sont pas ceux de La Banque mondiale. Contenu tiers - La Banque mondiale n’est pas nécessairement propriétaire de chaque élément du contenu de l’ouvrage. Par conséquent, La Banque mondiale ne garantit pas que l’utilisation d’un élément individuel appartenant à un tiers ou d’une partie de l’œuvre ne portera pas atteinte aux droits de ces tiers. Le risque de réclamations résultant d’une telle infraction vous incombe exclusivement. Si vous souhaitez réutiliser un élément de l’ouvrage, il vous appartient de déterminer si une autorisation est nécessaire pour cette réutilisation et d’obtenir l’autorisation du titulaire du droit d’auteur. Les exemples d’éléments peuvent comprendre, sans s’y limiter, des tableaux, des figures ou des images. Toutes les questions relatives aux droits et aux licences doivent être adressées à Groupe de la Banque mondiale, 1818 H Street NW, Washington, DC 20433, États-Unis ; courriel : pubrights@worldbank.org. TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 3 Remerciements Ce rapport a été rédigé par une équipe de la Banque mondiale composée de Blandine Wu Chebili (spécialiste senior en passation des marchés, EPSPA) et Hunt La Cascia (spécialiste senior en passation des marchés, EPSPA), ainsi que par une équipe de CKS Consulting composée de François Collineau (directeur et expert), Arnaud Salomon (directeur et expert), Baptiste Calvet (expert en technologie) et de la société SQUAD, Yoann Moreau (expert en sécurité). Le rapport a bénéficié des contributions des collègues de la Banque mondiale suivants et qui ont aimablement accepté de faire office de réviseurs : Felipe Goya (responsable des pratiques de passation de marchés, EAWRU), Anand Kumar Srivastava (spécialiste senior en passation des marchés, EAWRU), Knut J. Leipold (Spécialiste principal senior en passation des marchés, EAERU), et Khuram Farooq (spécialiste senior en gestion financière, EPSPA). Nous remercions tout particulièrement les partenaires des gouvernements du Rwanda, de l’île Maurice, de la Tunisie, de l’Ouganda et de la Côte d’Ivoire pour avoir partagé leurs expériences et leurs points de vue. 4 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Contenu Remerciements..................................................................................................................................................... 3 Glossaire................................................................................................................................................................ 7 Résumé exécutif................................................................................................................................................... 8 Contexte, objectifs et contenu de l’étude........................................................................................................ 9 Présentation des 3 types de mise en œuvre................................................................................................... 9 L’état de l’art en matière de sécurité informatique...................................................................................... 11 Enquête sur le marché des éditeurs d’e-GP................................................................................................. 11 Modélisation des coûts................................................................................................................................... 12 Ratios avantages-coûts (ratios BCR)............................................................................................................. 14 Résultats de l’analyse CBA (« Cost Benefits Analysis »).............................................................................. 15 Chapitre I - Contexte et définitions................................................................................................................... 19 Objectifs de l’étude sur les types de mise en œuvre de l’e-GP ?................................................................. 22 Chapitre II - Aperçu des différents types de mise en œuvre.......................................................................... 24 2.1 Aperçu des caractéristiques des projets de systèmes d’information.................................................... 25 2.2. Les logiciels CUSTOM............................................................................................................................. 26 2.3. COTS......................................................................................................................................................... 30 2.4. SaaS......................................................................................................................................................... 34 2.5 L’option « Logiciel Open Source » (Open-Source Software)................................................................... 38 2.6. Synthèse des principales différences entre les 3 modes de mise en œuvre........................................ 38 2.7. Questions liées à la sécurité informatique lors de l’implantation d’une e-GP..................................... 39 Chapitre III - Étude de marché.......................................................................................................................... 43 3.1. Présentation générale du marché global de l’e-procurement.............................................................. 44 3.2. Présentation du marché de l’e-GP.......................................................................................................... 48 Chapitre IV - Analyse coûts-avantages............................................................................................................ 68 4.1. Modèles de coûts CUSTOM, COTS et SAAS............................................................................................ 69 4.2. Analyse BCR............................................................................................................................................. 76 4.3. Analyse coûts-avantages (ACA)............................................................................................................... 78 4.4. Synthèse de l’analyse.............................................................................................................................. 93 Chapitre V - Le retour d’expérience................................................................................................................. 94 5.1. Introduction des études de cas............................................................................................................... 95 5.2. Étude de cas n° 1 : Rwanda.................................................................................................................... 96 5.3. Étude de cas n° 2 : la Tunisie................................................................................................................ 101 5.4. Étude de cas n°3 : Ouganda ................................................................................................................. 106 5.5. Étude de cas n° 4 : l’île Maurice ........................................................................................................... 110 5.6. Étude de cas n° 5 : Côte d’Ivoire........................................................................................................... 114 5.7. Accord-cadre SaaS e-GP pour les États du Nigéria............................................................................ 117 CONTENU I 5 Conclusion......................................................................................................................................................... 118 Références......................................................................................................................................................... 121 Annexe 1. Fiche de synthèse pour chaque développeur de logiciel................................................................ 125 Annexe 2. Questionnaire d’étude de marché................................................................................................... 135 Annexe 3. Matrice de collecte des données..................................................................................................... 142 Annexe 4. Principes fondamentaux de la sécurité informatique.................................................................... 145 Annexe 5. Les 10 principaux risques liés à la sécurité des applications Web................................................ 154 Tableau des schémas Schéma 1 : Les 2 principaux types de méthodologie de projet pour les projets de développement de logiciels CUSTOM �����������27 Schéma 2 : Processus de mise en œuvre et planification typique d’un COTS.................................................................... 31 Schéma 3 : Processus et planification typique de la mise en œuvre du SaaS................................................................... 35 Schéma 4 : Comparaison des caractéristiques des 3 types de mise en œuvre................................................................. 39 Schéma 5 : Parts de marché des éditeurs de suites e-procurement en 2019................................................................... 45 Schéma 6 : Informations générales sur le marché............................................................................................................. 46 Schéma 7 : Informations générales sur les éditeurs e-GP................................................................................................. 48 Schéma 8 : Cartographie des éditeurs basée sur l’analyse des résultats du questionnaire/de l’enquête ���������������������� 50 Schéma 9 : Couverture fonctionnelle, par caractéristique et par phase............................................................................ 52 Schéma 10 : Types de solutions fournies par les 18 fournisseurs ayant répondu à l’enquête.......................................... 53 Schéma 11 : Couverture fonctionnelle par type de solution................................................................................................ 54 Schéma 12 : Capacité à mettre en œuvre une solution e-GP en Afrique........................................................................... 55 Schéma 13 : Répartition la plus fréquente des phases de mise en œuvre........................................................................ 56 Schéma 14 : Analyse de la distribution des rôles de mise en œuvre.................................................................................. 57 Schéma 15 : Estimation du temps de mise en œuvre par type d’éditeur de logiciels..........................................................58 Schéma 16 : Expérience et acceptation des éditeurs de logiciels interrogés en ce qui concerne les systèmes sur site �������������60 Schéma 17 : Hébergement des données : hébergement sur site ou hors site.....................................................................61 Schéma 18 : Nombre de développeurs e-GP pour chaque entreprise de services d’hébergement................................. 61 Schéma 19 : Nombre de développeurs e-GP pour chaque entreprise de services d’hébergement................................. 62 Schéma 20 : Nombre de fournisseurs de solutions hébergeant des données sur chaque continent............................... 62 Schéma 21 : Editeurs e-GP qui font auditer leurs applications chaque année.................................................................. 64 Schéma 22 : Nombre de fournisseurs par modèle financier.............................................................................................. 65 Schéma 23 : Modèles de tarification.................................................................................................................................... 65 Schéma 24 : Montants estimés par les éditeurs de logiciels interrogés............................................................................ 65 Schéma 25 : Budget de Design et de Build par type de mise en œuvre............................................................................. 71 Schéma 26 : Impact des inducteurs de coûts sur le budget «Design & Build»................................................................. 72 Schéma 27 : Planification des phases de Design et de Build par scénario........................................................................ 73 Schéma 28 : Coûts cumulés de possession de l’e-GP sur 5 ans par type de mise en œuvre........................................... 74 6 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Schéma 29 : Complexité du projet par portée..................................................................................................................... 75 Schéma 30 : Durée moyenne des projets CUSTOM / COTS (avec un haut niveau de personnalisation)........................... 80 Schéma 31 : Décalage moyen par rapport au planning initial............................................................................................ 80 Schéma 32 : Atteinte des objectifs initiaux du projet............................................................................................... 83 Schéma 33 : Étude de cas e-GP - Rwanda........................................................................................................................... 96 Schéma 34 : Planification du projet UMUCYO...................................................................................................................... 97 Schéma 35 : Couverture fonctionnelle d’UMUCYO.............................................................................................................. 98 Schéma 36 : Guide YouTube du fournisseur UMUCYO....................................................................................................... 100 Schéma 37 : Etude de cas e-GP - Tunisie ......................................................................................................................... 101 Schéma 38 : Planification du projet TUNEPS.................................................................................................................... 102 Schéma 39 : Couverture fonctionnelle de TUNEPS........................................................................................................... 103 Schéma 40 : Etude de cas e-GP - Ouganda....................................................................................................................... 106 Schéma 41 : Planification du projet EPP............................................................................................................................ 107 Schéma 42 : Couverture fonctionnelle de l’EPS................................................................................................................. 108 Schéma 43 : Etude de cas e-GP - Ile Maurice................................................................................................................... 110 Schéma 44 : Planification du projet EPS............................................................................................................................ 111 Schéma 45 : Couverture fonctionnelle de l’EPS................................................................................................................. 112 Schéma 46 : Etude de cas e-GP - Côte d’Ivoire ................................................................................................................ 114 Schéma 47 : Planification du projet SIGOMAP......................................................................................................................115 Schéma 48 : Top 10 des risques de sécurité des applications (dernière version du top 10 de l’OWASP publiée en 2017) ���������� 147 Schéma 49 : Étapes présentant des risques de sécurité élevés dans un système e-GP...................................................151 TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 7 Glossaire Acronym Signification en anglais Signification en français BCR Benefits/costs ratio Rapport Avantages/Coûts CAGR Compound Annual Growth Rate Taux de Croissance Annuel Composé CBA Cost/Benefit Analysis Analyse Coûts/Avantages CF Cash flows Flux de Trésorerie COTS Commercial off-the-Shelf Logiciel prêt l’emploi D&B Design and Build Conception et construction de la solution e-GP electronic-Government Procurement Système en ligne de gestion des marchés publics pour les gouvernements EO Economic Operator Opérateur Economique EOI Expression of Interest Expression d'Intérêt ERP Enterprise Resource Planning Système de planification des Ressources de l'Entreprise GUI Graphical User Interface Interface Utilisateur ICT Information and Communications Technology Technologies de l'Information et des Communications IPF Investment Project Financing Financement de l’investissement projet IT Information Technology Technologies de l'Information OCDS Open Contracting Data Standard Norme de données pour les contrats ouverts P2P Procure-to-Pay De l’Approvisionnement au Paiement PPP Public-Private Partnership Partenariat Public-Privé PV Present value Valeur Actuelle RFI Request for Information Demande d'Information S2C Source-to-Contract De l’expression de besoin à la contractualisation SaaS Software-as-a-Service Logiciel en mode service SLA Service Level-Agreement Engagements sur les Niveaux de Services STP Source to Contract De l’expression de besoin au paiement T&E Time and Expenses Temps passés et dépenses TCO Total Cost of Ownership Coût Total de Possession WBG World Bank Group Groupe Banque Mondiale Résumé exécutif TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 9 Résumé exécutif Contexte, objectifs et contenu de l’étude Ces dernières années, de plus en plus de gouvernements africains cherchent à mettre en œuvre une solution e-GP afin de relever les défis associés aux marchés publics : • Harmoniser les processus internes pour optimiser leur exécution, • Accroître la transparence et la traçabilité, • Réaliser des gains financiers, • Faciliter l’accès aux marchés publics pour tous les acteurs économiques. Cette étude de la Banque mondiale vise à aider les gouvernements africains à mettre en œuvre une solution e-GP qui réponde au mieux à leurs besoins et contraintes. Cette étude aidera aussi les pays déjà dotés d’un système e-GP à le faire évoluer dans les meilleures conditions. Présentation des 3 types de mise en œuvre Les définitions des trois types de mise en œuvre peuvent être résumées comme suit : 1 Une solution CUSTOM désigne un logiciel qui a été développée spécifiquement pour les besoins d’une organisation donnée et qui n’est pas « packagée » pour la revente. 2 Une solution COTS (Commercial-Off-The-Shelf) désigne un logiciel acquis auprès d’un éditeur de logiciel (ou un logiciel « open-source ») qui est configuré par paramétrage et/ou qui peut être adapté avec une couche de code spécifique supplémentaire. 3 Une solution SaaS désigne un logiciel fourni comme un service partagé mis à disposition sur le web et qui peut être configuré par paramétrage (sans codage spécifique). Les principales différences entre les trois modes de mise en œuvre sont les suivantes : • Les projets CUSTOM nécessitent une expertise technique et des ressources plus importantes que les projets COTS/SaaS. • Les projets CUSTOM sont de loin les plus complexes à gérer. Ils requièrent de solides compétences fonctionnelles, techniques et en gestion de projet informatique. Ils impliquent également la participation active de la maîtrise d’ouvrage à toutes les étapes du développement. • Dans le cas des CUSTOM, le code source est la propriété du client (même si le développement est confié à une société informatique tierce). Sur les projets SaaS/COTS, le code source appartient à l’éditeur du logiciel et le client n’y a pas ou peu accès. 10 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE • Dans le cas des projets SaaS et COTS, le code source est issu du retour d’expérience de plusieurs clients, tandis que dans le cas d’une solution CUSTOM, le code source est personnalisé et adapté aux besoins spécifiques du client. • Dans les projets CUSTOM, la gestion de l’hébergement/des données est sous la responsabilité du client qui met généralement en œuvre un hébergement sur site. Pour les projets COTS, le client peut choisir entre un hébergement sur site et un hébergement externalisé, et même dans certains cas un mélange des deux solutions d’hébergement. Pour les projets SaaS, l’hébergement est sous la responsabilité de l’éditeur de logiciel et dans la plupart les des cas, l’hébergement des données se fait dans le cloud. • Avec les projets SaaS, la maintenance corrective/évolutive, le support utilisateurs (« helpdesk ») et les contrôles de sécurité sont de la responsabilité de l’éditeur de logiciel et/ou de son intégrateur. Toutes ces activités sont décrites dans un accord de niveau de service (SLA). Dans le cas des projets CUSTOM, toutes ces activités sont organisées et gérées par le client qui peut faire appel à des prestataires externes et/ou à des ressources pour ces activités. • Dans les projets CUSTOM, les budgets sont dimensionnés en fonction de la charge de travail requise pour l’ensemble des phases projet. Pour les projets SaaS et COTS, le modèle de tarification est basé sur un abonnement ou des licences d’utilisation et un budget de mise en œuvre. Le chapitre III de ce rapport explique en détail les différences entre les trois types d’un point de vue opérationnel, technique et contractuel, sur la base des axes suivants : Custom COTS SaaS Mixte Mixte Mixte Mixte Editeur de Integrateur Editeur de Integrateur Acteurs clés du design-build* ESN Dept. IT logiciel logiciel Organisation Editeur de Editeur de Acteurs clés du run ESN Dept. IT logiciel Integrateur logiciel Integrateur Intensité de la maîtrisse d’ouvrage faible moy. forte faible moy. forte low moy. forte Personnalisation du code faible moy. forte faible moy. forte low moy. forte Code Accessibilité du code accès accès accès accès accès accès fermé limité total fermé limité total fermé limité total Vend. Gvt. Vend. Gvt. Vend. Gvt. Sur site** ou Hors site Responsabilités Hébergement e sécurité des données Sur site** hors site Maintenance Support Sécurité de l’application t en license m Mode d’acquisition frais fixes T&E license abonnement ne on ab * Hors maîtrisse d’ouvrage (rôle tenu par le gouvernement). ** Hébergement sur le site du gouvernement que gère lui-même activité d’hébergement des données (pas d’externalisation). Source : auteurs RÉSUMÉ EXÉCUTIF I 11 L’état de l’art en matière de sécurité informatique Les discussions avec les différents représentants des pays africains ont mis en évidence l’intérêt d’une synthèse des enjeux et bonnes pratiques en matière de sécurité des systèmes d’information et des exigences essentielles à inclure dans les cahiers des charges e-GP (qu’il s’agisse de projets CUSTOM, COTS ou CUSTOM). Cette partie démontre clairement que les éditeurs de logiciels SaaS/COTS déploient beaucoup plus de ressources pour la sécurité des applications/des données que les solutions CUSTOM. Enquête sur le marché des éditeurs d’e-GP En mettant en commun la base de données de la Banque mondiale et les avis d’experts, 36 éditeurs de logiciels ayant la capacité de fournir des solutions de passation de marchés électroniques pour le secteur public ont été interrogés. 18 d’entre eux ont répondu à notre questionnaire détaillé. Trois types d’éditeurs de logiciels e-GP ont été identifiés : 1 Les éditeurs “full-suite”, qui proposent des suites couvrant l’ensemble du processus achat 2 Les éditeurs de solutions e-GP, qui se spécialisent dans l’optimisation des processus de passation et suivi des marchés publics. 3 Les éditeurs de logiciels “de niche”, qui concentrent leur expertise sur des fonctionnalités spécifiques. Les principales conclusions de l’étude de marché sont les suivantes : • Le domaine fonctionnel qui est le mieux couvert par les éditeurs de logiciels est la phase de “pré-attribution (Programmation, publication, appels d’offres en ligne, …) • Les modules les moins bien couverts par les éditeurs sont ceux liés à la phase de post- attribution, en particulier les fonctionnalités liées aux catalogues électroniques, à la signature électronique et à la gestion des litiges. • Tous les répondants ont déclaré qu’ils étaient en mesure de déployer leur solution en Afrique. Ceci, même si presque aucun de ces éditeurs de logiciels n’a de bureaux sur le continent africain. • Il existe une relative diversité de modèles d’organisation proposés par les éditeurs de logiciels. Trois répartitions principales des rôles entre les éditeurs de logiciels et leurs intégrateurs ont été identifiées (« Editeurs de logiciels offrant un service complet », « Editeur en charge du Build et intégrateur en charge du Run », « Intégrateur proposant un service complet »). • Seuls 15% des éditeurs de logiciels disposent de leurs propres « data centers » et proposent d’héberger les données des clients directement dans leurs locaux. La plupart des éditeurs de logiciels font appel à des prestataires de services d’hébergement de données. • L’hébergement sur site n’est pas la modalité privilégiée par les éditeurs de logiciels SaaS et COTS, car le support qu’ils peuvent offrir aux clients est généralement de moindre qualité dans ce cas. 66 % des éditeurs interrogés accepteraient d’envisager l’option d’hébergement sur site, mais seuls 44 % des éditeurs de logiciels interrogés l’ont déjà fait. • Enfin, il existe une relative diversité de modèles de tarification. Pour garantir une concurrence de qualité, les gouvernements doivent être en mesure d’inclure dans les documents d’appel d’offres un maximum de données chiffrées afin de permettre à tous les fournisseurs de produire un chiffrage fiable. 12 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Modélisation des coûts Un modèle de coût pour le périmètre fonctionnel étudié1 a été construit sur la base des données recueillies lors de l’étude de marché et de l’enquête menée auprès de 54 pays africains. 3 scénarios de projet ont été considérés : 1 Cas “théorique” : cas d’un projet sans événements imprévus et indésirables. 2 Cas « d’usage » qui comprend un certain nombre d’événements indésirables classiques sur les projets informatiques. 3 Cas « dégradé » qui simule un projet comportant un nombre significatif de difficultés/ événements indésirables. Budget total sur 5 ans et sensibilité aux inducteurs (K€) (Budget l’année N) Cas théorique Cas d’usage Cas dégradé 5,000 4,975 4,500 4,203 4,000 to m Cus 3,647 3,643 3,500 3,367 C OT S 3,242 3,000 2,916 2,640 S aa S 2,500 2,467 Source : auteurs 1. Programmation des achats en ligne, publication/notification en ligne, appels d’offres en ligne, évaluation/attribution en ligne, portail fournisseurs, gestion des fournisseurs, suivi et reporting. RÉSUMÉ EXÉCUTIF I 13 Cette partie combine les conclusions des précédents chapitres. Custom COTS SaaS Temps de mise en oeuvre Facilité du projet Adéquation de la solution Avantages Interopérabilité Maintenabilité Sécurité Souveraineté Coût total de possession Coûts Facilité de gestion du budget Risque d’échec Forte Modéré Faible Source : auteurs Les principales conclusions sont les suivantes : • Pour un même périmètre fonctionnel, les projets CUSTOM nécessitent un budget plus élevé que les projets SaaS ou COTS (50 à 70% de coûts supplémentaires). Cette tendance est visible dans les phases de Design et de Build, ainsi que dans le Run. • En outre, les projets CUSTOM sont plus sensibles aux inducteurs de coûts, et donc plus susceptibles de dériver d’un point de vue budgétaire. • En termes de planification, les projets CUSTOM ont tendance à durer plus longtemps que les projets COTS et SaaS. En outre, leur dérive calendaire en cas de difficulté est généralement plus importante. 14 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Ratios avantages-coûts (ratios BCR) Le ratio BCR permet de résumer l’intérêt d’un investissement en divisant la valeur actuelle des bénéfices attendus par la valeur actuelle des coûts générés. Si le BCR d’un projet est supérieur à 1,0, le projet est censé apporter une valeur actuelle nette positive à un gouvernement. Si le BCR d’un projet est inférieur à 1,0, les coûts du projet sont supérieurs aux avantages et le projet ne doit pas être envisagé. Le calcul des ratios avantages-coûts montre que : • Les projets CUSTOM ne sont pas intéressants pour les “petits” pays dont les dépenses de commande publique sont inférieures à 1 milliard de dollars. Dans le scénario “Cas d’usage”, le BCR est légèrement inférieur à 1, ce qui signifie que le pays a du mal à récupérer les fonds investis. En cas de difficultés importantes rencontrées pendant le projet CUSTOM (cas « dégradé »), l’investissement n’est pas du tout rentable. Pour ces petits pays, les projets COTS ne semblent pas non plus être très appropriés. Seuls les projets SaaS semblent présenter un avantage financier dans tous les scénarios pour ce groupe de pays. Cas Cas Cas théorique d’usage dégradé Custom 1.26 0.94 0.59 COTS 1.57 1.37 1.05 SaaS 2.20 1.95 1.58 • Pour les pays dont les dépenses en matière de marchés publics s’élèvent à 1,5 milliard de dollars, les trois types de mise en œuvre représentent un investissement intéressant dans le scénario “Cas d’usage”. Cependant, le scénario SaaS offre un retour sur investissement deux fois plus élevé que les projets CUSTOM et 42% plus élevé que les projets COTS. De plus, dans le cas « dégradé », le SaaS continue à offrir un bon retour sur investissement et les projets COTS un retour correct, ce qui n’est plus le cas pour le projet CUSTOM. Cas Cas Cas théorique d’usage dégradé Custom 2.27 1.72 1.06 COTS 2.83 2.47 1.90 SaaS 3.96 3.51 2.84 • Pour les pays dont les dépenses de marchés publics s’élèvent à 3 milliards, les 3 types de mise en œuvre représentent un investissement intéressant dans le scénario « Cas d’usage ». Cependant, le scénario SaaS offre un retour sur investissement presque deux fois plus élevé que les projets CUSTOM et 38% plus élevé que les projets COTS. De plus, dans le « cas dégradé », les solutions SaaS et COTS continuent d’offrir un bon retour sur investissement, ce qui est moins vrai pour le projet CUSTOM. Cas Cas Cas théorique d’usage dégradé Custom 4.01 3.00 1.84 COTS 4.97 4.40 3.39 SaaS 6.84 6.02 4.53 RÉSUMÉ EXÉCUTIF I 15 Résultats de l’analyse CBA (« Cost Benefits Analysis ») Cette partie compare les avantages et les inconvénients des différents modes de mise en œuvre sur la base des critères d’évaluation ci-dessous : Temps de mise en œuvre L’étude de terrain a mis en évidence que la durée des projets COTS (avec une proportion élevée de développements spécifiques) et CUSTOM est de 25 mois pour les phases de Design et de Build. La complexité de ces types de mise en œuvre entraîne souvent des dérapages dans les calendriers des projets. Les pays qui ont opté pour ces deux types de mise en œuvre ont constaté un écart d’environ 60 % par rapport au calendrier initial. Les projets SaaS et COTS avec une faible proportion de développements spécifiques sont plus courts si le processus d’acquisition a été mené de manière approfondie. Notre modélisation permet de conclure que le planning pour ces types d’implémentation est compris entre 9 et 13 mois. La facilité du projet du point de vue du gouvernement Les projets CUSTOM et COTS comportant une proportion importante de développements spécifiques sont des projets très exigeants du point de vue du “client”. Les équipes de gestion de projet partent de zéro et ne s’appuient généralement pas sur des expériences passées. Elles doivent également couvrir toutes les dimensions associées au processus de développement informatique et doivent coordonner de nombreux intervenants et expertises. A l’inverse, les projets SAAS et COTS avec des développements spécifiques limités bénéficient de la simplification d’une solution pré-packagée et de l’expérience du déploiement de l’application auprès de nombreux clients. Il y a moins d’expertise technique à mobiliser et à coordonner. La gestion de projet est donc moins mobilisée par les questions techniques et se concentre davantage sur la manière de modéliser les attentes fonctionnelles dans les modules de la solution retenue. Adéquation de la solution L’adéquation d’une solution informatique peut s’évaluer de deux façons : la capacité à répondre aux exigences des utilisateurs finaux et la facilité d’utilisation. En théorie, le principal attrait des logiciels CUSTOM (et des solutions COTS avec un niveau élevé de développements spécifiques) est que toutes les exigences peuvent être satisfaites. Toutefois, l’étude des projets de ce type mis en œuvre en Afrique montre que les gouvernements n’ont pas obtenu exactement ce qu’ils voulaient. La difficulté de rédiger des spécifications fonctionnelles détaillées au début du processus de développement et les contraintes de ressources/techniques conduisent à une situation où toutes les exigences ne sont pas satisfaites. De leur côté, les solutions SaaS d’e-GP répondent à la plupart des besoins car elles intègrent au fil du temps les meilleures pratiques de nombreux organismes publics dans le développement du produit. Cependant, certaines spécificités dans les règles de gestion ou des processus très spécifiques seront plus difficiles à traduire dans la solution. En ce qui concerne la facilité d’utilisation, les éditeurs de SaaS et de COTS sont engagés dans une véritable course à l’amélioration de “l’expérience utilisateur” et améliorent leur convivialité en se basant sur les retours de milliers d’utilisateurs. Il est plus difficile pour les projets CUSTOM de rivaliser sur ce point et de mobiliser toute l’expertise nécessaire comme les ingénieurs en interface utilisateur (UI) et/ou en expérience utilisateur (UX). 16 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Interoperability Les solutions COTS et SaaS sont généralement livrées avec des outils d’intégration de données (boîte à outils API, connecteurs), qui permettent de se connecter à des systèmes tiers. En outre, les éditeurs de logiciels COTS et SaaS ont l’expérience du développement d’interfaces pour leurs multiples clients, et leurs logiciels sont parfois conçus pour s’intégrer nativement aux applications “grand public” telles que SAP ou ORACLE par exemple. Dans le cas des projets CUSTOM, toutes les interfaces sont conçues au moment de la création du système, ce qui nécessite d’affecter des compétences techniques et des ressources importantes à cette tâche. Maintenabilité La maintenabilité peut être définie comme la facilité d’administration “ au jour le jour “ du système, tant sur le plan technique que fonctionnel, et la capacité à améliorer le système dans le temps. En mode SaaS/COTS, l’éditeur du logiciel se charge des modifications et des mises à jour nécessaires à l’intégration des différentes briques et composants logiciels qui composent la solution. Dans le monde des projets CUSTOM, c’est à l’équipe technique de faire les études d’impact, le développement et les tests. D’un point de vue temps et coût, cela est forcément plus coûteux qu’en mode SaaS, qui répartit l’effort et le coût sur l’ensemble des clients. Par ailleurs, en mode SaaS, des fonctionnalités permettant à des ressources “ non techniques “ de prendre en charge l’administration fonctionnelle sont développées. En effet, les solutions SaaS anticipent l’administration fonctionnelle dans leur conception alors qu’il est plus difficile d’anticiper les besoins réels en termes d’administration fonctionnelle sur des projets CUSTOM. Les solutions SaaS intègrent en permanence les commentaires des clients dans leur feuille de route. L’étude de marché montre que les éditeurs de logiciels SaaS/COTS interrogés réalisent au moins une version majeure de leur produit chaque année (et jusqu’à deux versions majeures par an). Toutefois, l’éditeur de logiciels décide lui-même de l’ordre de priorité des demandes d’évolution qu’il reçoit de tous ses clients. En d’autres termes, un client donné n’est pas sûr que ces demandes d’évolution soient rapidement prises en compte. En théorie, les logiciels CUSTOM permettent aux clients d’ajouter ou de supprimer des fonctionnalités à la volée. Mais en pratique, une fois le logiciel construit, la plupart de l’équipe de projet est dissoute et réaffectée à d’autres projets. Même lorsque ce n’est pas le cas, chaque évolution du produit est un mini-projet qui demande du temps et de l’argent. Sécurité En ce qui concerne la sécurité informatique, il y a deux dimensions différentes à prendre en compte : 1 La sécurité des applications et des infrastructures 2 La sécurité des données Assurer la sécurité d’une application et d’une infrastructure nécessite des composants logiciels, des audits et des processus coûteux. En ce qui concerne la sécurité des applications, il est communément admis par la communauté de la cybersécurité que choisir une application SaaS/ COTS d’un éditeur de logiciels de confiance est plus sûr dans la mesure où ce dernier est plus à même de réaliser ces investissements. RÉSUMÉ EXÉCUTIF I 17 Souveraineté La souveraineté peut être analysée selon deux dimensions : la souveraineté des données et l’autonomie dans la gestion et l’évolution du système. Les solutions CUSTOM et COTS sont généralement associées à un hébergement sur site. En Afrique, une tendance semble se développer en faveur de « data centers » mutualisant l’hébergement de l’ensemble des solutions informatiques utilisées par les gouvernements, ce qui offre des garanties substantielles de souveraineté des données. Quelques exemples de ces “clouds gouvernementaux” sont détaillés dans les études de cas. La plupart des systèmes SaaS e-GP sont hébergés dans le cloud. Mais cela ne signifie pas qu’il n’y a aucune garantie de souveraineté. Il est techniquement possible que la solution soit hébergée dans un « data center » dans le pays du client ou que l’éditeur accepte sous certaines conditions d’héberger la solution dans les locaux du client. Par ailleurs, la plupart des éditeurs de solutions SaaS e-GP proposent une architecture “single-tenant” (multi-instance) qui garantit le cloisonnement total des données entre les clients. Il est également possible d’exiger un cryptage des données au niveau du serveur qui rend les données inaccessibles à toute personne ayant un accès physique aux « data centers ». Les 3 modes permettent au client d’avoir le contrôle sur l’administration de l’outil au quotidien. Dans le mode CUSTOM, cela se fera en pérennisant les équipes qui ont géré la phase projet et la gestion du changement. Il est important de prévoir le financement de ces équipes au-delà de la phase projet, comme l’ont souligné plusieurs pays interrogés. Dans les projets COTS et SaaS, la souveraineté implique un transfert de savoir-faire de l’éditeur de logiciels vers les équipes gouvernementales : la formation des administrateurs et leur accompagnement pendant la phase de transfert doivent être précisément décrits dans le cahier des charges et le contrat de l’éditeur de logiciels/intégrateur. Par ailleurs, le gouvernement pouvant exercer une influence limitée sur la feuille de route de l’éditeur de logiciels, il est donc important de s’assurer que celui-ci couvre bien les besoins fonctionnels qui ne sont pas implémentés dans la première vague du projet. Il est également possible de demander aux éditeurs de logiciels de s’engager à fournir une fonctionnalité qui n’est pas actuellement disponible. Coût total de possession Le modèle de coût a montré que les projets de mise en œuvre de solutions CUSTOM ou COTS avec une part élevée de développements spécifiques coûtent deux fois plus cher que les projets de mise en œuvre de solutions SaaS. En outre, le coût total de possession sur 5 ans pour les projets CUSTOM est 60% plus élevé que pour les projets SaaS ou COTS avec une faible part de développement spécifique. Il y a également une plus forte tendance à la dérive budgétaire pour les projets CUSTOM/COTS avec une forte part de développements spécifiques. Facilité de gestion du budget La gestion du budget est plus facile sur les projets SaaS et COTS avec une faible part de développements spécifiques. Sur ces projets, les budgets sont plus faciles à gérer car le gouvernement obtient plus facilement une vision définitive des coûts liés à un périmètre fonctionnel donné. Les modèles de tarification adoptés par les éditeurs de logiciels SaaS/COTS sont également intéressants pour leur flexibilité. Le montant des licences s’adaptera au déploiement progressif du logiciel. Dans le modèle CUSTOM et COTS avec une part importante de développements spécifiques, les coûts du projet sont imputés au projet indépendamment de l’utilisation réelle de la solution. 18 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Risques d’échec Tout d’abord, les risques liés au processus d’acquisition de la solution ne doivent pas être sous- estimés. Sur les projets CUSTOM, il est parfois difficile d’évaluer la capacité d’une équipe de développeurs internes ou externes à produire l’application souhaitée. Sur les projets SaaS/ COTS, le risque est de réaliser une étude insuffisamment détaillée des capacités des solutions du marché (en termes de fonctionnalités, d’intégration, de capacités d’administration, etc.) et de finalement choisir une solution éloignée des attentes prioritaires et incompatible avec les contraintes du gouvernement. Les différentes enquêtes ont également montré que le risque de dérapage budgétaire et calendaire est beaucoup plus important pour les projets CUSTOM et les projets COTS avec une forte proportion de développements spécifiques. L’étude de terrain a clairement montré que ces projets présentent également un écart important entre l’ambition fonctionnelle initiale et la réalisation effective. Enfin, deux risques importants doivent également être pris en compte pour la réussite du projet à long terme : le risque de dépendance et le risque d’obsolescence. Le risque de dépendance est plus élevé sur les projets CUSTOM. Les compétences informatiques étant rares et difficiles à retenir, il existe toujours une dépendance à certains profils clés. Dans les projets SaaS/COTS, il existe un réel risque de dépendance vis-à-vis de l’éditeur de logiciels et/ou de l’intégrateur qui peut être le seul à pouvoir réaliser des évolutions complexes par exemple. Ce risque est toutefois gérable si les différents cas de figure sont prévus contractuellement. Le risque d’obsolescence ne doit pas non plus être sous-estimé et tend à être plus élevé pour les projets CUSTOM. La difficulté de suivre les évolutions technologiques ne doit pas être sous-estimée. Il est de plus en plus difficile de faire les bons choix et de suivre l’évolution des « frameworks », des langages et des composants informatiques... En ce sens, le modèle SaaS/COTS est plus confortable car la mise à jour technologique de l’application est déléguée à l’éditeur du logiciel qui la gère de manière mutualisée pour tous les clients. Chapitre I Contexte et définitions 20 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Chapitre I Contexte et définitions L’e-Government Procurement (e-GP) est défini par la Banque mondiale comme “l’utilisation d’un système d’information transactionnel par les institutions gouvernementales et autres organisations du secteur public pour mener et gérer leurs activités d’achat et leurs relations avec les fournisseurs pour l’acquisition de travaux, de biens et de services nécessaires au secteur public”. “Il ne doit pas être confondu avec l’e-procurement, qui est un terme générique désignant l’utilisation des technologies de l’information et de la communication pour traiter et gérer une ou toutes les étapes transactionnelles du processus d’approvisionnement. Un système d’e-GP peut donc être considéré comme un système e-procurement décliné et conforme à la réglementation des marchés publics. Concrètement, la mise en œuvre de l’e-GP implique la mise en place au niveau national d’applications web qui sécurisent et améliorent l’efficacité et la transparence des marchés publics, de la planification des soumissionnaires à la gestion des contrats en passant par l’émission des bons de commande. Dans ses précédents rapports sur le sujet, la Banque mondiale a précisé les domaines fonctionnels couverts par les solutions e-GP2. La couverture fonctionnelle idéale d’un système e-GP complet comprend les trois domaines suivants : 1 La phase de pré-attribution, depuis la planification de l’activité jusqu’aux résultats du processus d’évaluation, 2 La phase post-attribution, de l’attribution du contrat à sa clôture, 3 Les fonctionnalités qui viennent en appui du processus achats Couverture fonctionnelle Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité Source : auteurs 2. E-Procurement Toolkit: E-Procurement Preparation http://eprocurementtoolkit.org/sites/default/files/2016-10/e-Procurement_ Preparation-Rapid_e-Procurement_Toolkit.pdf I 21 Idéalement, un système e-GP devrait également répondre aux caractéristiques techniques suivantes : • Capacité d’intégration des données : capacité du système e-GP à communiquer avec d’autres systèmes existants en envoyant, collectant et traitant des données. • Garantie de souveraineté et sécurité des données et de l’application. • Fiabilité et disponibilité de l’application (garantie par un « Service Level Agreement ») • Flexibilité du système : capacité à évoluer et à proposer de nouvelles fonctionnalités dans des budgets maîtrisés Interface with the accounting Integration tools to seamlessly systems in order to receive the communicate with all back-end systems Examples amounts of liquidated orders and Strong and third-party business services: of common monitor the expenditure on contracts integration • Enterprise Application interface interfaces capabilities (EAI toolbox) to help orchestrate the on e-GP Web service interface with public/ data trasnfer with external systems systems external supplier database to ensure • API console to deploy, manage and test the existence/compliance of the suppliers Location of the datacenters Reliability and availability High security standards Hosted in the country of the system guaranteed by service level agreement (SLA) - Security of the data Technical • Or hosted in a country that has (authentication, back-up, ratified the Malabo Agreement prerequisites Flexibility of the system to recovery plan) • Or hosted in a country subject to adapt to organizational changes - Application security RGPD, with a provider that does not (encryption of the database, present any risk of extraterritoriality Scalability intrusion prevention, etc.) Source : auteurs L’Accord de Malabo (convention de l’Union africaine sur la cybersécurité et la protection des données personnelles)3 vise à renforcer et à harmoniser la législation des pays de l’Union africaine dans le domaine de la cybersécurité et de la protection des données. Il vise à créer un cadre normatif pouvant servir de base à la conception de lois, et couvre 3 activités spécifiques majeures : 1 Les transactions électroniques. 2 La protection des données à caractère personnel. 3 La cybersécurité et la lutte contre la cybercriminalité. 3. https://au.int/en/treaties/african-union-convention-cyber-security-and-personal-data-protection. 22 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Objectifs de l’étude sur les types de mise en œuvre de l’e-GP ? Pour aider les gouvernements dans leurs choix, la Banque mondiale a réalisé une analyse comparative des trois types de mise en œuvre : CUSTOM, Commercial-Off-The-Shelf (COTS), et Software-as-a-Service (SaaS). La Banque Mondiale a également réalisé une étude de marché auprès des éditeurs de logiciels e-GP. En lisant cette analyse comparative, les pays clients seront mieux à même de prendre des décisions éclairées sur l’approche à adopter en matière de systèmes e-GP. L’étude pourra aussi compléter leurs connaissances sur la mise en œuvre des logiciels e-GP et leur processus d’exploitation et de maintenance. Il convient de noter que si les conclusions et recommandations sont applicables à n’importe quel autre pays, le rapport se concentre spécifiquement sur la région africaine. L’Afrique accuse aujourd’hui un retard significatif par rapport au reste du monde en ce qui concerne la dématérialisation des marchés publics. Les gouvernements africains sont particulièrement intéressés par les premiers retours d’expérience sur le continent africain. L’analyse de marché s’est ainsi focalisée sur les expériences et les capacités de déploiement des éditeurs en Afrique et l’enquête terrain a été menée auprès des pays africains (avec notamment 5 pays interviewés en détail sur leur initiative e-GP). Bien que le public principal de ce rapport soit les autorités gouvernementales et les experts en marchés publics, les entreprises privées, y compris les éditeurs, les consultants et les fournisseurs de services, bénéficieront également de l’analyse approfondie décrite dans le rapport. L’étude s’ouvre sur une description des 3 différents types de mise en œuvre : CUSTOM, COTS et SaaS (chapitre II). Cette partie explique les spécificités de chaque type de mise en œuvre en matière de terminologie, de méthodologie et de modèle financier. Les caractéristiques spécifiques de chaque mode, l’organisation typique du projet, les profils/expertises types à mobiliser, le partage des responsabilités entre le client et les différents intervenants et enfin la méthodologie traditionnellement mise en œuvre, ainsi que les avantages et les limites de chaque type d’implémentation sont décrits. CHAPITRE I - CONTEXTE ET DÉFINITIONS I 23 Le chapitre III suivant fournit des détails sur l’analyse du marché de l’e-GP. Plusieurs études de marché sur les solutions STC et P2P ont été réalisées par des sociétés d’études telles que Gartner ou Forrester. Cependant, il n’existe aucune étude qui se concentre sur le sous-ensemble qui représente le marché des solutions e-GP. Le chapitre III comprend une cartographie des différents éditeurs de logiciels ou entreprises ayant développé une solution e-GP, ainsi que plusieurs analyses sur les principales caractéristiques du marché : • Les différents types d’éditeurs e-GP sur le marché • Un classement des fonctionnalités les mieux/les moins bien couvertes sur le marché • Une analyse des modèles de mise en œuvre les plus utilisés • Une analyse des politiques d’hébergement des données et de sécurité des applications • Une analyse des modèles de tarification et des prix du marché • Une évaluation de la capacité des éditeurs de solutions e-GP à déployer leur solution en Afrique. • Une fiche de synthèse par éditeur de logiciels Toutes ces informations devraient permettre aux gouvernements d’avoir une vue d’ensemble des tendances du marché et d’adapter leur stratégie de mise en œuvre de l’e-GP et leurs cahiers des charges. La méthodologie suivante a été appliquée pour la préparation de l’étude de marché : • 36 éditeurs de logiciels ont été présélectionnés comme éditeurs potentiels de solutions e-GP. • Un questionnaire d’étude de marché a été élaboré (voir annexe 2) afin d’analyser le profil de chaque éditeur, sa couverture fonctionnelle, son modèle de mise en œuvre, sa politique d’hébergement/sécurité et son modèle de tarification. • Le questionnaire a été envoyé directement aux éditeurs de logiciels pré-qualifiés. Afin d’obtenir un maximum de réponses, la Banque Mondiale a également publié le questionnaire “ étude de marché “ sur la plateforme www.wbgeconsult2.org. • 18 questionnaires complétés ont été reçus (soit un taux de réponse de 50%). Le chapitre IV comprend la modélisation financière des coûts du projet et une comparaison des coûts récurrents entre les types de mise en œuvre. Il comprend également une analyse du retour sur investissement des 3 modes de mise en œuvre en utilisant l’approche des « Benefits Costs Ratios » (BCR). Toutes les analyses précédentes sont ensuite synthétisées dans une « Cost Benefit Analysis » (CBA) (chapitre IV.3) qui analyse la pertinence des types de mise en œuvre sur 10 critères. Enfin, le chapitre V détaille le principales études de cas en Afrique et les résultats de nos entretiens. Chapitre II Aperçu des différents types de mise en œuvre TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 25 Chapitre II Aperçu des différents types de mise en œuvre Les caractéristiques de chaque type de mise en œuvre décrites dans cette section sont valables pour les projets du secteur public comme ceux du secteur privé. 2.1 Aperçu des caractéristiques des projets de systèmes d’information 2.1.1 Les phases de mise en œuvre du système d’information Il est tout d’abord très important de comprendre la différence entre les ESN, les éditeurs de logiciels et les intégrateurs. Le terme “ESN” est un terme générique qui désigne les entreprises offrant tous types de produits et services informatiques. Cela inclut les éditeurs de logiciels, les intégrateurs, les sociétés de services d’hébergement, entre autres. Le terme “d’éditeur de logiciels” désigne uniquement les entreprises qui développent et commercialisent leurs propres logiciels. Enfin, un intégrateur est une entreprise qui soutient le gouvernement (le client) tout au long du processus de mise en œuvre du système e-GP.4 L’intégrateur de système peut être l’éditeur de logiciels lui- même, ou un autre ESN (y compris dans certains cas des sociétés de conseil). There are generally three different phases of software implementation: 1 La phase de Design. Il s’agit de la phase durant laquelle l’éditeur de l’e-GP (ou l’intégrateur, le cas échéant) se concentre sur la définition des fonctionnalités demandées par le client. La phase de conception est généralement basée sur les spécifications fournies par le gouvernement pendant la phase d’acquisition, combinées à des ateliers fonctionnels et techniques avec les chefs de projet et les utilisateurs finaux. Au cours de cette phase, la solution cible est spécifié dans le détail : rôles des futurs utilisateurs, flux de données avec d’autres systèmes, processus de bout en bout... Ensuite, l’éditeur de logiciels (ou l’intégrateur, le cas échéant) définit une stratégie de mise en œuvre (ressources requises pour la phase de construction, planification du projet, organisation des tests, etc.). La phase de Design a lieu au début du projet et requiert la participation de toutes les parties prenantes. 2 La phase de Build. Il s’agit de la phase durant laquelle l’éditeur e-GP (ou l’intégrateur, le cas échéant) construit la solution, sur la base des besoins identifiés durant la phase de Design. Cette phase est divisée en plusieurs étapes : développement (ou configuration/ «customization »), test et déploiement du logiciel. Bien entendu, un développement (ou une configuration/ «customization ») de qualité réduit considérablement le nombre de tests et les problèmes futurs liés à la maintenance. 4. Project Management Institute: IS/IT system implementation projects, tools and techniques for success: https://www.pmi.org/ learning/library/new-systems-upgrading-existing-implementations-453 26 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 3 La phase de Run. Cette phase comprend l’adoption du système e-GP par les utilisateurs finaux, mais aussi les activités de support et de maintenance. Une fois le système déployé, il y a encore beaucoup de travail lié à la maintenance du logiciel. Tout d’abord, il y a les corrections à appliquer. En outre, tous les utilisateurs finaux doivent être formés, et soutenus régulièrement lorsqu’ils rencontrent des anomalies ou lorsqu’ils comprennent mal une fonctionnalité. Enfin, avec la généralisation de l’utilisation du logiciel viendra le besoin de nouvelles fonctionnalités ou d’évolutions. 2.1.2 Différentes approches pour développer un système e-GP Il existe différentes approches en matière de gouvernance de la mise en œuvre des systèmes e-GP : 1 Propriété et exploitation par le gouvernement. Le gouvernement développe et exploite le système e-GP, en s’appuyant sur ses propres ressources internes. Parfois, le gouvernement peut demander l’aide d’un tiers pour soutenir une ou plusieurs phases du projet, mais ces partenaires externes n’ont pas la propriété intellectuelle du système. Ils ne font que fournir des services informatiques ou de conseil. 2 Service géré par le gouvernement. Le gouvernement ne possède pas le système e-GP qui est développé, détenu et exploité par un tiers. Cependant, le gouvernement reste propriétaire des données et supervise directement les services d’assistance (y compris l’assistance aux utilisateurs, la formation, etc.). En général, le gouvernement s’appuie sur des ressources internes (équipes et matériel) pour soutenir la phase de déploiement. 3 Partenariat public-privé (PPP). Dans ce modèle, le système est développé et exploité par une tierce partie. Toutefois, après une certaine période, la propriété du système est souvent transférée au gouvernement. 2.2. Les logiciels CUSTOM Les logiciels CUSTOM font référence à des solutions sur mesure qui sont développées en fonction des besoins d’une organisation donnée et qui ne sont pas « packagées » pour la revente. Le développement en mode CUSTOM est notamment utilisé pour concevoir des logiciels sur des fonctionnalités très spécifiques que les éditeurs du marché ne proposent pas. 2.2.1. Organisation Phases de Design et de Build • La plupart du temps, le développement de logiciels CUSTOM est assuré par un tiers mandaté par le client. La solution peut également être conçue par une équipe interne de développeurs. Ce dernier est cas est moins fréquent : les ressources internes ne sont peut- être pas formées ou expérimentées dans la technologie requise et ne seront peut-être pas disponibles sur l’ensemble du cycle de développement. • Lorsqu’un client décide de lancer un projet CUSTOM, il part souvent “de zéro » et doit couvrir toutes les dimensions associées au processus de développement informatique. Un projet CUSTOM passe par les étapes familières que sont la collecte des exigences, la construction du code, les tests et le déploiement. Ce type de projet requiert une bonne maîtrise des CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 27 méthodes de gestion de projets informatiques comme Agile, DevOps ou Rapid Application Development (veuillez-vous référer au schéma 1 - les deux principaux types de méthodologie de projet pour les projets de développement de logiciels CUSTOM). Les phases de Design et Build d’un logiciel CUSTOM nécessitent des ressources et une expertise importante. L’équipe classique au sein de l’éditeur de logiciels est généralement constituée des profils suivants : • Un architecte système qui définit la structure du système d’information et identifie les contraintes technologiques • Un designer UI (« User Interface ») en charge de l’interface utilisateur • Un designer UX (« User Expérience ») qui se charge d’améliorer la navigation des utilisateurs • Les ingénieurs « front-end » qui développent le côté client (partie de l’application avec laquelle les utilisateurs interagissent et sur laquelle ils envoient des requêtes). • Les ingénieurs « back-end » qui s’occupent du côté serveur (stockage et organisation des données, garantie du bon fonctionnement du côté « client »). • Un chef de projet technique ou un développeur principal (dit « lead developer ») • Des ressources pour installer et gérer les infrastructures techniques (serveurs) pendant la phase du projet. Schéma 1 : Les deux principaux types de méthodologie de projet pour les projets de développement de logiciels CUSTOM Méthodologie en cascade + Des étapes clairement définies Gather specifications - Séparation des tâches entre les équipes fonctionnelles et techniques Design Build & - Exige que les utilisateurs sachent dès le départ ce dont ils ont besoin (plutôt que configure d’essayer et d’affiner). Test - Délais de réalisation plus longs Produce - Plus de risques de retouches Méthodologie agile + Changements flexibles et adaptables Prototype Prioritize Agile sprint + Plus rapide (temps de réalisation) Work cycle for sub-deliverables + Plus facile à aligner sur l’activité + Risque réduit Configure or develop Test with users - Peut être plus complexe à gérer Source : auteurs 28 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Le client apporte l’expertise fonctionnelle : • Un « product owner » qui est responsable de la hiérarchisation des fonctionnalités et de la planification de l’étendue du travail pour les prochains mois. En d’autres termes, le « product owner » est le point de connexion entre l’équipe projet et les utilisateurs. Cette ressource doit avoir une compréhension approfondie des besoins en matière de gestion des marchés publics. • Des utilisateurs clés qui contribueront à la hiérarchisation des besoins et participeront aux phases de test. • Les clients sont également souvent assistés par un cabinet de conseil qui les oriente dans leurs choix sur les fonctionnalités. Le cabinet de conseil fournit généralement aussi une assistance opérationnelle pour suivre le planning et les indicateurs de mise en œuvre du projet (assistance à la maîtrise d’ouvrage). Dans les projets CUSTOM, la phase de tests (ou de « recette ») de la solution peut être très chronophage et complexe : • Étant donné que le logiciel est le plus souvent conçu à partir de zéro, il est nécessaire d’effectuer plusieurs séries de tests “unitaires” pour s’assurer qu’il n’y aura pas d’anomalies majeures liées au code. • En outre, les tests finaux d’acceptation (ou recette « de bout en bout) par les utilisateurs constituent souvent une étape laborieuse. Une solution développée sur mesure nécessite souvent de nombreux tests avant de fournir une expérience utilisateur agréable et efficace. PHASE DE RUN Dans la plupart des cas, la maintenance corrective (correction des anomalies) et la maintenance évolutive (nouvelles fonctionnalités) sont effectuées par l’ESN qui a été choisie pour développer la solution. Les gouvernements cherchent parfois à réinternaliser la maintenance pour gagner en autonomie. Cette démarche n’est pas toujours aisée. En effet, la formation des ressources internes à la maintenance de la solution peut prendre des mois. Ce processus peut également être très complexe, en fonction des choix techniques qui ont été faits lors de la conception (langage de codage retenu, framework utilisé, ...). INTENSITÉ DU PROJET POUR LA MAÎTRISE D’OUVRAGE La participation active du client est requise à toutes les étapes et notamment pour :   • La hiérarchisation des besoins : l’équipe projet doit avoir une connaissance approfondie de son organisation et de ses processus de passation de marchés, afin de rédiger des spécifications exhaustives et cohérentes. • Le test du logiciel toutes les 2 à 3 semaines afin que l’équipe puisse apporter des ajustements mineurs en cours de route, évitant ainsi les extensions de projet dues à des modifications majeures à la fin du cycle projet. • Le suivi des indicateurs qualité et planning du projet et la prise d’actions correctives. CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 29 2.2.2. Personnalisation et propriété du code • Le code est adapté aux besoins du gouvernement, qui peut théoriquement reproduire dans l’outil tous ses processus et règles de gestion. Le danger peut alors être de calquer des modes de fonctionnement redondants ou inutiles dans le système e-GP. En fonction du budget disponible, un logiciel CUSTOM peut permettre au client d’ajouter, de supprimer des caractéristiques selon les besoins, ou de modifier les fonctionnalités au fur et à mesure que l’organisation évolue et se développe. • Comme le code développé devient la propriété du gouvernement, il n’y a pas de restrictions théoriques sur l’accès au code. Il convient de veiller à ce que les clauses de transfert de la propriété intellectuelle des ESN au client soient correctement formulées et conformes à la réglementation en vigueur. 2.2.3. Responsabilités Hébergement : • La gestion de l’hébergement et des données est sous la responsabilité du gouvernement qui décide des modalités d’hébergement : hébergement sur site (exploité par les ressources ou géré par un prestataire de services), ou hébergement hors site géré par un prestataire de services d’hébergement, spécialisé dans le cloud. Entretien : • La maintenance corrective (correction des anomalies) est le plus souvent confiée à l’ESN qui a développé l’application ou est confiée à des équipes mixtes internes/externes. • En matière de maintenance évolutive (nouvelles fonctionnalités à développer), le gouvernement définit les nouvelles fonctionnalités qui seront développées. Les demandes d’évolution sont ensuite qualifiées, chiffrées et gérées par l’ESN ou l’équipe interne responsable de la maintenance évolutive. Support utilisateurs : • Le support utilisateurs (Helpdesk) est le plus souvent confié à l’ESN qui a développé l’application ou est confié à des équipes mixtes internes/externes. Sécurité des applications et des données : • Les équipes techniques des clients ont un contrôle total sur les politiques de sécurité et de protection des données. Les protocoles de sécurité doivent être revus en permanence (pour plus d’informations, veuillez-vous reporter au chapitre 2.6 - Principes fondamentaux de la sécurité). Le client doit s’assurer que tous les tiers concernés ont mis en place des procédures et des politiques strictes. Le chapitre 2.6 décrit les meilleures pratiques en matière de sécurité des applications et des données. 2.2.4. Mode d’acquisition • Le chiffrage est fonction du temps de développement nécessaire au projet. Sur les projets CUSTOM, le chiffrage contient souvent des contingences et ne sont pas « gravées dans le marbre ». Les coûts initiaux de développement d’un logiciel CUSTOM sont en effet beaucoup 30 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE plus élevés que les coûts de mise en œuvre d’une solution pré-packagée et des dépassements sont fréquents. (Veuillez-vous référer à l’analyse CBA au chapitre IV). • L’hébergement sur site nécessite également l’acquisition de matériel et de ressources supplémentaires (installations et électricité) pour gérer l’infrastructure. 2.3. COTS L’acronyme “COTS” signifie Commercial-Off-The-Shelf. L’industrie du logiciel n’a pas une compréhension commune de ce qu’est un produit COTS. C’est l’un des termes les plus diversement définis dans l’univers informatique et il peut renvoyer à des divers cas de figure. Pour éviter tout parti pris, nous avons adopté la définition suivante : Un système COTS est un logiciel disponible dans le commerce et acquis auprès d’un éditeur de logiciels ou un logiciel « open-source », qui est soit utilisé sans adaptation, soit adapté via configuration ou soit adapté par l’ajout de développements spécifiques (« customization »). 2.3.1. Organisation PHASE DE DESIGN ET DE BUILD Comme la plupart des fonctionnalités sont déjà développées, les projets COTS suivent un processus assez différent des projets CUSTOM, avec plus d’efforts consacrés à l’analyse des exigences fonctionnelles, aux tests et à l’interfaçage (et évidemment moins à la conception et au développement du code). Veuillez-vous référer à l’illustration 2 - processus de mise en œuvre et planification typique des COTS. Moins de ressources (personnel, savoir-faire et machines) sont nécessaires par rapport à un projet CUSTOM. L’équipe type sur un projet COTS est composée de : • Ressources chez les l’éditeur de logiciel et/ou chez l’intégrateur certifié : • Experts techniques chargés de la conception générale/détaillée de la solution cible : imbrication des différents modules, modélisation de flux de données et des interfaces nécessaires... • Experts techniques en charge de la configuration (paramétrage des modules) et/ou du code personnalisé fournissant les fonctionnalités manquantes. (“adware” ou “customizing”) • Des experts fonctionnels qui aident à hiérarchiser les besoins du gouvernement et à les intégrer dans la solution. Les questions clés sont les suivantes : Comment « mapper » nos processus métier dans les différents modules ? Quelles sont les principales règles de gestion à configurer ? Quelles données historiques allons-nous faire migrer vers le nouveau système ? Quels sont les points d’interface avec nos systèmes existants ? 5 • Les experts fonctionnels jouent un rôle clé car ils guident la qualification, la priorisation et la validation des besoins des utilisateurs. Ce rôle requiert un minimum de connaissances techniques (connaissance du modèle de données, des possibilités et des limites de la solution choisie) et de réelles capacités interpersonnelles. Les projets COTS doivent accepter une certaine flexibilité dans les exigences. Lorsqu’un COTS est sélectionné, certaines exigences sont immédiatement satisfaites, d’autres deviennent faciles à mettre en œuvre et d’autres encore peuvent être plus difficiles, voire impossibles, à obtenir. • Tous les éditeurs de logiciels ou intégrateurs ne disposent pas des compétences fonctionnelles nécessaires pour permettre au client de faire ces compromis essentiels. 5. https://www.oecd.org/tax/forum-on-tax-administration/publications-and-products/introducing-a-commer- cial-off-the-shelf-software-solution.pdf CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 31 Ce rôle est donc parfois assuré par une société de conseil tierce. Le cabinet de conseil fournit généralement aussi une assistance opérationnelle pour suivre la mise en œuvre du projet (assistance à la maîtrise d’ouvrage). Schéma 2 : Processus et planification typique de la mise en œuvre d’un COTS Le schéma ci-dessus présente le pourcentage de temps alloué à chaque phase d’un projet de mise en œuvre d’un logiciel COTS (basé sur les données recueillies dans le cadre de 40 projets de mise en œuvre menés par CKS Consulting). Phase 1: Phase 2: Phase 3: Phase 4: Development & Design User testing Finalization implementation General design based Development and Complete testing Data transfer and on prototype implementation via “delivery of the solution by the general deployment loops”, based on a 1st version end users • System of the configured solution architecture • UAT (User • Configuration acceptance testing) • Requirement analysis • Development of interface • Discrepancy resolution • Mapping of the requirement of the solution • Identification • Custom development of adware development • Adware integration • Unitary testing 30% 60% 80% 90% 100% Several implementation sprints (V1, V2, ...) Source : auteurs PHASE DE RUN Dans la plupart des cas, la maintenance corrective (correction des anomalies) est effectuée par l’éditeur du logiciel ou l’intégrateur. En ce qui concerne la maintenance évolutive (nouvelles fonctionnalités), plusieurs situations se présentent : • Tout d’abord, il peut s’agir d’activer un nouveau module disponible dans la « suite » logicielle retenue initialement. Dans ce cas, l’éditeur ou l’intégrateur du système se chargera de la mise en œuvre en suivant la même méthodologie que pour le périmètre initial. • Il peut également s’agir de modifier une configuration déjà réalisée (modification des règles de gestion, ajout d’un « workflow » complexe...). Le partenaire intégrateur est généralement mandaté, qualifie l’effort d’adaptation, envoie des devis et réalise les modifications. Dans le cas d’une modification du code spécifique qui a été ajouté initialement au logiciel (« customizing »), le processus est le même. 32 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE • Dans certains cas, l’évolution souhaitée n’est pas possible dans le logiciel COTS. Dans ce cas, l’éditeur du logiciel reste l’ultime décideur des fonctionnalités disponibles et du calendrier des versions. Par conséquent, le client n’a que peu ou pas d’influence sur les questions ci- dessus dans la mesure où elles affectent l’application. L’une des solutions correctives les plus courantes dans un tel cas consiste à ajouter du code personnalisé aux composants pour fournir les fonctionnalités manquantes.6 INTENSITÉ DE L’APPROPRIATION DE LA GESTION DU PROJET La contribution du gouvernement à la mise en œuvre du projet e-GP est moins intense que pour un projet CUSTOM. Le rôle du client se concentre sur les activités suivantes : • Définition et hiérarchisation des besoins de l’entreprise. Le client doit développer un cadre d’évaluation structuré, informé par les besoins et les priorités des principales parties prenantes afin d’assurer l’alignement organisationnel. Par exemple, le client doit évaluer s’il est possible d’adapter les processus existants afin de limiter l’effort de configuration et/ou de « customizing ». • Assurer la gouvernance globale du projet et les comités de pilotage qui permettent d’arbitrer les décisions fonctionnelles. • Assurer la mobilisation des équipes internes pour que le produit réponde aux attentes, notamment lors des phases de test. • Assurer la coordination des éditeurs de logiciels sur les plans technique, administratif et commercial.7 2.3.2. Personnalisation et propriété du code Le code source est basé sur les commentaires de plusieurs clients et n’est pas, par définition, personnalisé selon les besoins d’un seul client. Cela ne signifie pas que les fonctionnalités ne peuvent pas être personnalisées. Il existe deux possibilités pour personnaliser un logiciel COTS : • La « customization » : cela nécessite que l’équipe technique modifie un programme ou écrive un nouveau programme pour satisfaire de nouveaux besoins. Les « customizations » peuvent être basiques ou beaucoup plus invasives (modification de l’application de base). Dans la plupart des cas, le code spécifique ajouté au système e-GP original est la propriété du gouvernement, selon les termes du contrat négocié avec le développeur e-GP. • Configuration : Utilisation d’outils de paramétrage dans l’application afin de répondre à des exigences spécifiques sans ajouter de code spécifique à la solution. Ces termes ne sont pas toujours bien compris, ce qui entraîne une certaine confusion. • La « customization » signifie plus d’efforts et plus de risques. En effet, un programmeur développe de nouvelles fonctionnalités sans utiliser les outils disponibles dans le système, mais en ajoutant du nouveau code. En cas de mise à niveau d’une version (qui permet aux clients de bénéficier de nouvelles fonctionnalités ou d’une meilleure expérience utilisateur, par exemple), certaines parties de ce code spécifique peuvent devenir incompatibles. Ces « morceaux de codes » sont généralement assez compliqués et coûteux à maintenir dans le temps. Les clients essaient donc de les éviter en modifiant les processus ou en trouvant des solutions de contournement en mode « configuration ». 6. https://www.pmi.org/learning/library/CUSTOM-off-the-shelf-strategy-6137 7. https://www.oecd.org/tax/forum-on-tax-administration/publications-and-products/introducing-a-commer- cial-off-the-shelf-software-solution.pdf. CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 33 • La configuration signifie moins d’efforts et moins de risques. La configuration est beaucoup plus stable car elle ne modifie pas la solution au-delà de ce qui était prévu lors de sa conception. En effet, la configuration se base uniquement sur les outils existants de paramétrage dans la solution, qui permettent de modifier les fonctionnalités d’une certaine manière. La configuration ne modifie pas la structure de la solution. La configuration est intrinsèquement meilleure car elle travaille au sein de l’application, en utilisant des fonctionnalités existantes qui ont été conçues spécifiquement pour modifier l’application. L’accessibilité et la propriété du code : • Dans la plupart des cas, l’accès au code est impossible ou limité. • Les solutions COTS peuvent également être open source, ce qui garantit l’accès au code. Le gouvernement peut alors créer une déviation du code source (créer une branche variante du code à partir du code source). 2.3.3. Responsabilités Hébergement : • Dans le paysage des solutions COTS, Il existe un mélange d’hébergement sur site et d’hébergement hors site qui tend à devenir la norme. Dans le premier cas, l’hébergement de solution et la sécurisation des données deviennent la responsabilité du gouvernement. Dans le second cas, la responsabilité incombe à l’éditeur de logiciels. Maintenance : • Dans la plupart des projets, la maintenance est assurée par un intégrateur spécialisé. Il existe également des cas où la maintenance corrective et évolutive est réalisée par un « mix » d’équipes internes et externes.. Support utilisateurs : • Les éditeurs de logiciels proposent généralement un service de premier niveau qui traite les demandes simples : gestion des mots de passe, création/modification des utilisateurs et des droits... Ces services d’assistance externes traitent également avec les utilisateurs des questions fonctionnelles et techniques. Sécurité des applications et des données : • Si la solution est implémentée “Out of box” ou a été personnalisée par configuration, la responsabilité de la sécurité de l’application incombe à l’éditeur du logiciel. Ces solutions sont régulièrement testées par des équipes spécialisées et/ou des tiers et bénéficient de mises à jour de sécurité automatiques. Si un code spécifique a été ajouté (« customization »), la responsabilité est généralement partagée entre l’éditeur du logiciel, l’intégrateur qui a réalisé le code et le client. La section 2.7 décrit les meilleures pratiques en matière de sécurité des applications et des données. 2.3.4. Mode d’acquisition Le client ne possède pas le logiciel et paie pour le droit de l’utiliser. Il existe deux modèles financiers proposés par les éditeurs de logiciels COTS : la licence perpétuelle et l’abonnement. 34 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE • L’achat d’un logiciel avec une licence perpétuelle permet au client d’utiliser le logiciel pour une période indéfinie en payant une seule redevance initiale. En outre, le client paie également la maintenance et les autres frais d’assistance sur une base annuelle. Il s’agit du modèle “historique” d’achat de logiciels. D’un point de vue comptable, le client va généralement capitaliser le coût d’acquisition du logiciel. Pour la bonne tenue de ses comptes, le client doit alors évaluer la durée de vie utile estimée de ce logiciel et amortir le coût, en utilisant une méthode d’amortissement acceptable. • Au cours de la dernière décennie, de nombreux éditeurs de logiciels COTS ont modifié leur modèle de revenus, passant d’une licence perpétuelle à un modèle basé sur l’abonnement. Dans ce modèle, le client effectue des paiements réguliers chaque année (ou chaque trimestre/mois) pour utiliser le logiciel. Une différence essentielle entre les deux modèles réside dans le fait que les abonnements comprennent tout : le droit d’utiliser le logiciel, la maintenance et le support technique (alors que les licences à durée déterminée ne comprennent que le droit d’utiliser le logiciel). D’un point de vue comptable, la transaction est considérée comme un contrat de service et l’entreprise doit généralement imputer le coût d’abonnement en « charge de fonctionnement » sur la période où elle signe le contrat. Ce modèle présente l’avantage de réduire les coûts initiaux et d’éviter les longues procédures d’approbation des dépenses d’investissement. Il est également nécessaire d’obtenir un devis pour le service de mise en œuvre du logiciel (conception, réalisation et gestion des changements). L’éditeur de logiciels et/ou son intégrateur fournira alors un devis à prix fixe qui dépend du nombre d’ateliers à réaliser, du nombre de fonctionnalités à mettre en œuvre, du nombre d’interfaces et de la complexité du projet. 2.4. SaaS SaaS” est l’abréviation de “Software-as-a-Service” (logiciel en tant que service). Il s’agit d’un logiciel fourni au consommateur sous la forme d’un service (partagé) mis à disposition sur le web, sans hébergement ni installation. Toutes les activités et les efforts de développement, la gestion de l’infrastructure et les efforts de maintenance sont ainsi mutualisés entre tous les utilisateurs de la solution. L’éditeur de logiciel SaaS est ainsi responsable de la gestion des composants logiciels, de l’hébergement, de la maintenance et d’autres services. 2.4.1. Organisation PHASES DE DESIGN ET DE BUILD Le processus de mise en œuvre et l’organisation du projet sont assez similaires à ceux des projets de type COTS, avec davantage d’efforts consacrés aux exigences, aux tests et à l’intégration (et évidemment moins à la conception et au code). Veuillez-vous référer à l’illustration 3 - processus de mise en œuvre et planification typique de SaaS. Moins de ressources sont nécessaires par rapport à un projet CUSTOM/COTS. L’équipe type est composée de : • Ressources chez l’éditeur du logiciel et/ou chez l’intégrateur certifié : • Experts techniques chargés de la conception générale/détaillée de la solution cible : imbrication des différents modules, modélisation de flux de données et des interfaces nécessaires… CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 35 • Experts techniques chargés de la configuration (paramétrage des modules). • Sur les projets SaaS, l’objectif est d’exclure tout développement spécifique (“customizing”). C’est également la raison pour laquelle le niveau moyen de qualification technique sur ces projets est plus faible par rapport aux projets COTS. Les ressources impliquées sont certifiées sur le logiciel retenu mais n’ont pas nécessairement une formation académique dans le domaine informatique. Elles utilisent des outils de configuration prédéveloppés dans la solution sans avoir à travailler directement sur le code. • Les experts fonctionnels qui aident à hiérarchiser les besoins de l’entreprise. Ils guident la qualification, la priorisation et la validation des besoins des utilisateurs. Ce rôle requiert un minimum de connaissances techniques (connaissance du modèle de données, des possibilités et des limites de la solution choisie) et des capacités relationnelles importantes. Sur les projets SaaS, certaines exigences sont faciles à mettre en œuvre en utilisant les capacités de configuration du logiciel retenu, et d’autres peuvent être plus difficiles, voire impossibles à obtenir. Les gouvernements doivent dans ce cas être prêts à adapter certains de leurs processus très spécifiques afin que ces derniers « s’adaptent » à la solution retenue. Dans le processus de sélection, Il est donc important de voir comment les spécificités réglementaires/procédurales peuvent être prises en compte par les éditeurs SaaS. Tous les éditeurs de logiciels ou intégrateurs ne disposent pas des compétences fonctionnelles nécessaires pour permettre au client d’effectuer ces arbitrages clés. Ce rôle est donc parfois assuré par une société de conseil tierce. Le cabinet de conseil fournit généralement aussi une assistance opérationnelle pour suivre la bonne mise en œuvre du projet (assistance à la maîtrise d’ouvrage). Schéma 3 : Processus et planification typique de la mise en œuvre d’une solution SaaS Le schéma ci-dessus présente le pourcentage de temps alloué à chaque phase d’un projet de mise en œuvre d’un logiciel SaaS (basé sur les données recueillies dans le cadre de 40 projets de mise en œuvre menés par CKS Consulting). Phase 1: Phase 2: Phase 3: Phase 4: Development & Design User testing Finalization implementation General design based Development and Complete testing Data transfer and on prototype implementation via “delivery of the solution by the general deployment loops”, based on a 1st version end users • System of the configured solution architecture • UAT (User • Configuration acceptance testing) • Requirement analysis • Development of interface • Discrepancy • Integration tests resolution • Mapping of the requirement of the solution 30% 60% 80% 90% 100% Several implementation sprints (V1, V2, ...) Source : auteurs 36 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE PHASE DE RUN La maintenance corrective (correction des anomalies) est effectuée par le développeur du logiciel ou un intégrateur certifié. Concernant la maintenance évolutive (nouvelles fonctionnalités), plusieurs cas de figure doivent être différenciés : • Tout d’abord, il peut s’agir d’activer un nouveau module disponible dans la « suite » logicielle retenue. Dans ce cas, l’éditeur et/ou l’intégrateur du système se chargera(ont) de la mise en œuvre en suivant la même méthodologie que pour le périmètre initial. • Il peut également s’agir de modifier une configuration déjà réalisée (modification des règles de gestion, mise en place d’un «workflow » complexe). Dans ce cas précis, le partenaire intégrateur est généralement mandaté, qualifie l’effort d’adaptation, envoie des devis et réalise les modifications. • Dans certains cas, l’évolution souhaitée n’est pas possible en l’état du logiciel SaaS. En mode SaaS, tout développement spécifique visant à combler une faiblesse fonctionnelle de l’outil est en théorie proscrit. C’est la une différence majeure ave les projets COTS qui autorisent l’ajout d’«adware » (« customization »). L’éditeur de logiciel reste le décideur ultime sur les fonctionnalités disponibles et sur le calendrier des versions. La capacité d’influencer la feuille de route de l’éditeur de logiciel (sa « roadmap ») dépend notamment du poids du client sur l’activité globale de l’éditeur de logiciel. INTENSITÉ DU PROJET POUR LA MAÎTRISE D’OUVRAGE Le rôle du client se concentre sur les activités suivantes : • Définition et hiérarchisation des besoins de l’entreprise. Le client doit développer un cadre d’évaluation structuré, documenté relatifs aux besoins et aux priorités des principales parties prenantes afin d’assurer l’alignement organisationnel. Par exemple, le client doit évaluer s’il est possible d’adapter certains processus existants afin de limiter l’effort de configuration. • Assurer la gouvernance globale du projet et les comités de pilotage qui permettent d’arbitrer les décisions fonctionnelles. • Assurer la mobilisation des équipes internes pour que le produit réponde aux attentes, notamment lors des phases de test. • Assurer la coordination des différents acteurs sur les plans technique, administratif et commercial 2.4.2. Personnalisation et propriété du code Personnalisation : Le code source n’est par définition pas personnalisé en fonction des besoins d’un client. La solution peut être personnalisée par une configuration (utilisation d’outils de paramétrage disponible dans l’application afin de répondre à des exigences spécifiques sans modification du code source). La « customization » (écriture de nouveaux programmes, fichiers de classe, scripts…) est théoriquement exclue sur les projets SaaS. En outre, les éditeurs de logiciels SaaS n’autorisent pas l’accès au code source (sauf cas très particulier). CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 37 2.4.3. Responsabilités Hébergement : • La responsabilité de l’hébergement incombe à l’éditeur du logiciel. Toutes les activités d’hébergement de données et le maintien d’un niveau de sécurité adéquat sont décrits dans un SLA (Service Level Agreement) entre le gouvernement et l’éditeur de logiciel. Entretien : • La maintenance corrective et évolutive est gérée par l’éditeur du logiciel et/ou par l’intégrateur (notamment sur les configurations réalisées dans le cadre du projet) Support utilisateurs : • Le support utilisateurs est géré à la fois par l’éditeur du logiciel et/ou l’intégrateur. Les éditeurs de logiciels offrent généralement un service de premier niveau qui traite les demandes simples : gestion des mots de passe, création/modification des utilisateurs et des droits. Ces services d’assistance externes traitent également les problèmes fonctionnels des utilisateurs. Sécurité des applications et des données : • Cette responsabilité incombe à l’éditeur de logiciel. Toutes les activités d’hébergement de données et le maintien d’un niveau adéquat de sécurité des applications sont décrits dans un SLA entre le client et l’éditeur de logiciels. La section 2.6 décrit les meilleures pratiques en matière de sécurité des applications et des données. 2.4.4. Mode d’acquisition • Au cours de la dernière décennie, la plupart des éditeurs de logiciels SaaS a modifié leur modèle de revenus, passant d’une licence perpétuelle à un modèle basé sur l’abonnement. Dans ce modèle, le client effectue des paiements réguliers chaque année (ou chaque trimestre/mois) pour utiliser le logiciel. Une différence essentielle entre les deux modèles est que les abonnements comprennent tout : le droit d’utiliser le logiciel, la maintenance et le support technique (alors que les licences à durée déterminée ne comprennent que le droit d’utiliser le logiciel). D’un point de vue comptable, la transaction est considérée comme un contrat de service et le client impute le coût en charge de fonctionnement sur la période d’utilisation. Ce modèle présente l’avantage de réduire les coûts initiaux et d’éviter les longues procédures d’approbation des dépenses d’investissement. • La plupart des éditeurs de SaaS acceptent encore sous certaines conditions de contracter en mode “licence perpétuelle”. L’achat d’un logiciel avec une licence perpétuelle permet au client d’utiliser le logiciel pour une période indéfinie en payant un seul montant initial. En outre, le client paie également les frais de maintenance et autres frais d’assistance sur une base annuelle. Il s’agit du modèle “historique” d’achat de logiciels. D’un point de vue comptable, le client va généralement capitaliser le coût d’acquisition du logiciel. Pour la bonne tenue de ses comptes, le client devra évaluer la durée de vie utile estimée de ce logiciel et amortir le coût, en utilisant une méthode d’amortissement acceptable. 38 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Il est également nécessaire d’obtenir un devis pour le service de mise en œuvre du logiciel (conception, réalisation et gestion des changements). L’éditeur de logiciels et/ou son intégrateur fournira alors un devis à prix fixe qui dépend du nombre d’ateliers à réaliser, du nombre de fonctionnalités à mettre en œuvre, du nombre d’interfaces, et de la complexité du projet. 2.5 L’option « Logiciel Open Source » (Open-Source Software) Un logiciel libre (Open-Source Software, OSS) est une application construite par une communauté de développeurs et à laquelle tout le monde peut accéder et qu’il est possible d’améliorer. Les OSS sont créés pour être librement disponibles, et leur licence indique généralement que toute mise à jour des contributeurs deviendra gratuite et accessible par l’ensemble de la communauté. Les OSS ne doivent pas être confondus avec les “ normes ouvertes “ qui désignent une norme de mise en œuvre comme HTML et SQL. Par ailleurs, l’Open Source ne doit pas être confondu avec l’Open Architecture qui désigne des architectures de conception privées dont les spécifications sont rendues publiques par les concepteurs. Dans l’étude e-GP, le logiciel Open Source n’a pas été considéré comme un type de mise en œuvre distinct. Il existe quelques exemples de projets e-GP basés sur une solution OSS, mais les couches de développement spécifiques ajoutées les rendent finalement assez souvent similaires aux projets COTS en termes de caractéristiques « projet ». En théorie, les logiciels libres offrent des avantages indéniables tels que des économies sur les coûts de licence, des délais avantageux (l’outil est immédiatement disponible), et la mise en commun des efforts entre “clients” pour améliorer le système. En réalité, les logiciels Open Source ont tendance à être moins facilement personnalisables que les solutions COTS ou SaaS du marché. Il peut également être difficile ou coûteux de trouver des profils ou des entreprises compétentes capables de configurer/personnaliser l’OSS. Le coût de la mobilisation des ressources peut alors effacer complètement les économies réalisées sur le coût des licences. En outre, le choix du logiciel libre implique de “parier” sur le dynamisme à long terme de la communauté qui développe et améliore le logiciel. Il est clairement établi que de nombreuses solutions OSS voient leur communauté décliner au fil du temps, rendant le produit obsolète. Ce problème est régulièrement pointé du doigt, notamment en ce qui concerne la capacité des modèles OSS à détecter et à corriger les failles de sécurité. Avant de s’orienter vers un OSS, les gouvernements devraient étudier attentivement le dynamisme de la communauté à travers des indicateurs tels que le nombre de développements effectués, ou le nombre de “loads” récemment effectuées. 2.6. Synthèse des principales différences entre les 3 modes de mise en œuvre Le diagramme ci-dessous compare les principales caractéristiques des 3 modes de mise en œuvre sur plusieurs dimensions : • Organisation du projet de mise en œuvre • Les types d’acteurs impliqués dans les phases de Design (conception de la solution) et de Build (mise en œuvre technique et tests). • Les types d’acteurs impliqués dans la phase Run (administration et maintenance de l’application). • L’intensité de la gestion du projet, c’est-à-dire l’effort que le client doit produire pour mener à bien la mise en place du système e-GP. CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 39 • Personnalisation, accessibilité et propriété du code source. • Répartition des responsabilités entre les parties concernées en matière d’hébergement, de maintenance, de service d’assistance et de sécurité des applications. • Les différents modes d’acquisition. Pour la région africaine, le SaaS n’est clairement pas le type d’implémentation qui domine mais il est potentiellement promis à un bel avenir car il constitue une alternative intéressante. La solution SaaS récemment mise en œuvre dans les États du Nigéria et l’expérience positive dans les îles des Caraïbes devraient encourager les pays africains à mieux considérer ce type d’implémentation. Schéma 4 : Comparaison des caractéristiques des 3 types de mise en œuvre Custom COTS SaaS Mixte Mixte Mixte Mixte Editeur de Integrateur Editeur de Integrateur Acteurs clés du design-build* ESN Dept. IT logiciel logiciel Organisation Editeur de Editeur de Acteurs clés du run ESN Dept. IT logiciel Integrateur logiciel Integrateur Intensité de la maîtrisse d’ouvrage faible moy. forte faible moy. forte low moy. forte Personnalisation du code faible moy. forte faible moy. forte low moy. forte Code Accessibilité du code accès accès accès accès accès accès fermé limité total fermé limité total fermé limité total Vend. Gvt. Vend. Gvt. Vend. Gvt. Sur site** ou Hors site Responsabilités Hébergement e sécurité des données Sur site** hors site Maintenance Support Sécurité de l’application t en license m Mode d’acquisition frais fixes T&E license abonnement ne on ab * Hors maîtrisse d’ouvrage (rôle tenu par le gouvernement). ** Hébergement sur le site du gouvernement que gère lui-même activité d’hébergement des données (pas d’externalisation). Note : Dans la partie Organisation “Acteurs clés des phases “Design-Build” et “Run” ; la taille de la cellule varie en fonction de la fréquence du “schéma” (elle ne varie pas en fonction de la contribution de chaque acteur). L’analyse est basée sur 40 projets de mise en œuvre menés par le CKS au cours des 10 dernières années. Source: auteurs 40 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 2.7. Questions liées à la sécurité informatique lors de l’implantation d’une e-GP Le nombre de cyberattaques n’a jamais augmenté aussi rapidement. Une étude récente de l’institut Ponemon a révélé que les entreprises dépensent 3,86 millions de dollars par incident et qu’au cours des deux dernières années, les organisations ont perdu environ 400 milliards de dollars à cause du vol et de la fraude informatiques, dans le monde entier8. Ce coût comprend à la fois les dommages directs (temps d’arrêt des infrastructures, perte de réputation) et les dommages indirects.9 En ce qui concerne la sécurité informatique, il y a deux dimensions différentes à prendre en compte : Sécurité des Exigences visant à garantir la confidentialité, l’intégrité et la données disponibilité des données Exigences imposées au développeur pour identifier, prévenir et corriger Sécurité des toutes les vulnérabilités des applications aux différentes étapes du cycle applications de vie du produit 2.7.1. Conditions préalables à la sécurisation d’un système e-GP Afin de garantir qu’un système e-GP reste sécurisé, un certain nombre de principes doivent être respectés : 1 Sensibilisation des employés aux risques de sécurité : s’assurer que les utilisateurs gouvernementaux sont conscients des risques de sécurité et connaissent les meilleures pratiques pour assurer la sécurité de l’application (pas de partage de login, pas d’ouverture de liens suspects, etc.) 2 Sécuriser le développement de l’application : s’assurer qu’il n’y a pas de risque de sécurité ou de vulnérabilité lors du développement ou de la mise à jour de la solution. Cette tâche est généralement beaucoup plus coûteuse et longue pour le gouvernement dans les projets CUSTOM que dans les projets COTS ou SaaS, car le gouvernement doit tout gérer lui-même (former l’équipe de développement, mettre en œuvre un logiciel de contrôle de la sécurité, etc.) 3 Assurer la protection de l’infrastructure : s’assurer que le matériel dédié à l’hébergement des données et les serveurs sont sûrs. Une fois encore, la protection de l’infrastructure tend à être beaucoup plus coûteuse dans les projets CUSTOM que dans les projets COTS ou SaaS. En effet, dans les projets CUSTOM, le gouvernement doit mettre en place des mesures de protection telles que des pares-feux, des logiciels de détection d’intrusion ou des sauvegardes de données dans différents centres de données. Dans les projets SAAS et COTS, ces mesures sont entièrement prises en charge par l’éditeur de logiciel e-GP (qui mutualise l’effort sur de multiples clients) 4 Assurer l’évolutivité et la tolérance aux pannes de la solution : Il est important de s’assurer que les ressources informatiques peuvent s’adapter en cas d’augmentation ou de diminution de l’activité de la solution. Les solutions COTS et SAAS permettent aux gouvernements de ne pas investir beaucoup dans une infrastructure supplémentaire pour répondre à ce type de besoins, alors que les projets CUSTOM e-GP nécessitent que le gouvernement mette en place du matériel supplémentaire pour implémenter de nouveaux accès. 5 Utilisez la cryptographie sur les applications et sur les transferts de données : Pour 8. https://www.capita.com/sites/g/files/nginej291/files/2020-08/Ponemon-Global-Cost-of-Data-Breach-Study-2020.pdf. protéger la confidentialité des données, il est important de rendre illisibles ces dernières par des personnes non autorisées. L’utilisation du chiffrement pour ce faire est la méthode 9. https://www.nbcnews.com/tech/security/ponemon-institute-n364871. CHAPITRE II - APERÇU DES DIFFÉRENTS TYPES DE MISE EN ŒUVRE I 41 la plus courante et peut également être complétée par l’utilisation de la blockchain, qui est souvent considérée comme la meilleure option de sécurité en termes d’intégrité des données. Le type de mise en œuvre n’a aucun impact sur la méthodologie de cryptage des données (les méthodes restent les mêmes pour tous les types). 6 Stratégie IAM (Identity and Access Management) et systèmes de provisionnement des comptes : La gestion des identités et des accès (IAM) consiste à définir et à gérer les rôles et les privilèges d’accès des utilisateurs aux applications. Dans le cas des systèmes SaaS/ COTS, les fournisseurs de « cloud computing » proposent le plus souvent une solution IDaaS (Identity as a Service) et peuvent la mettre en œuvre avec votre accord sur votre environnement, ajoutant ainsi une couche supplémentaire de sécurité à l’accès aux données. 7 Disposer d’un plan de réponse aux incidents de sécurité : s’assurer qu’en cas d’attaque, le gouvernement sera en mesure d’y faire face rapidement. Dans les projets SAAS ou COTS, l’éditeur du système e-GP est responsable des plans de réponse et dispose généralement de ressources formées et dédiées, prêtes à répondre à de tels crises. Dans les projets CUSTOM, le gouvernement doit maintenir son équipe de sécurité et mettre à jour son plan de réponse de sécurité sur une base régulière, ce qui tend à être coûteux et à prendre du temps. En conclusion, le maintien de la sécurité d’un système e-GP est souvent exigeant et coûteux. Dans un projet e-GP CUSTOM, le gouvernement doit généralement gérer seul l’infrastructure, ainsi que la formation des utilisateurs et des développeurs internes, ce qui représente un investissement important. Il est donc nécessaire, lors de l’estimation du budget d’un projet de système e-GP personnalisé, d’inclure une partie dédiée à la sécurité informatique dans le budget final. Les projets COTS et SAAS permettent de libérer le gouvernement de ces questions techniques, rendant le coût de la sécurité souvent plus faible puisqu’il est partagé avec les autres clients de l’éditeur de logiciel e-GP. L’utilisation d’une solution SAAS ou COTS peut réduire l’investissement nécessaire à l’administration pour sécuriser ses systèmes e-GP. Mais le gouvernement doit tout de même fournir un effort important pendant la phase d’achat, pour s’assurer que les considérations de sécurité sont prises en compte convenablement par les éditeurs. En effet, le gouvernement doit s’assurer que l’offre sélectionnée répondra parfaitement aux besoins de sécurité, en vérifiant si le système e-GP fait l’objet d’un audit régulier, si l’architecture de l’infrastructure est suffisamment sécurisée et en évaluant les éléments des offres liés à la sécurité informatique (tels que les plans de sauvegarde, les procédures de reprise après sinistre et les certifications par exemple). 2.7.2. Données et étapes e-GP à sécuriser en premier lieu Il y a 3 types de données qui peuvent être à risque dans un système e-GP : 42 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Faible valeur de revente Les données et assez faciles à restaurer Faible niveau de risque publiques Exemple : cahier des charges, fournisseurs attribués, nombre et montant des contrats, etc. L’altération/la suppression de ce type Les données non de données peut paralyser un processus Niveau de risque publiques à faible de passation de marchés. moyen/faible valeur de revente Exemple : Évaluation des fournisseurs, adresses, noms des responsables, etc. Business secret information, which could Non-public data damage the supplier’s activities and with high compromise ongoing procurement processes. High risk level resale value Example: detailed offers of the suppliers (business secret). The e-GP steps that could represent a risk in terms of data security are the following: These processes concentrate most of the sensitive information related to business secrecy and the alteration or deletion of the data has no doubt the most important consequences for the contracting authorities. A hacking could indeed lead to important consultation delays, Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité Source : auteurs cancellations, delays in government projects, and serious damages for some companies, if confidential information were made public. Chapitre III Étude de marché 44 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Chapitre III Étude de marché L’étude de marché est structurée comme suit : 1. Elle commence par un rapide aperçu du marché mondial des solutions d’e-procurement, en mettant en évidence ses chiffres clés, ses tendances et ses principaux acteurs. 2. La partie 3.2 se concentre sur le marché des solutions e-GP en tant que sous-ensemble du marché global. Cette partie comprend une cartographie des différents développeurs de solutions e-GP et des fiches d’information sur les éditeurs (pour ceux qui ont répondu au questionnaire de l’étude de marché). L’objectif principal est de fournir un aperçu général des offres existantes. Cette section comprend plusieurs analyses sur les principales caractéristiques du marché : • Les différents types d’éditeurs de logiciels e-GP actifs sur le marché • Un classement des fonctionnalités les mieux/les moins bien couvertes sur le marché • Une analyse des principaux modèles de mise en œuvre sélectionnés pour les projets e-GP • Une analyse des politiques d’hébergement des données et de sécurité des applications • Une analyse des modèles de tarification utilisés par es éditeurs de logiciels et des « prix de marché » pour les différentes composantes d’un projet e-GP. L’analyse du marché comprend également une évaluation de la capacité/intérêt des éditeurs de logiciels à déployer leur solution sur le continent africain. 3.1. Présentation générale du marché global de l’e-procurement 3.1.1. Chiffres clés du marché des développeurs de suites e-procurement Selon une étude menée par Appsruntheworld10, la valeur du marché des éditeurs de logiciels d’e- Procurement en 2015 était d’environ 4 978 millions de dollars. En 2019, il avait augmenté de 15 % pour atteindre 5 680 millions de dollars. D’ici 2024, les prévisions estiment que le marché continuera de croître pour atteindre une valeur d’environ 6 360 millions de dollars, ce qui équivaut à un CAGR d’environ 2,4 %. Une autre étude, réalisée par Forrester Research estime la valeur mondiale du marché à 8 milliards de dollars en 2019, et prévoit une croissance fulgurante sur 5 ans. Le secteur connaît une croissance annuelle significative, qui s’explique par le renforcement du positionnement de la fonction achats dans les organisations privées et publiques. Cette montée en puissance de la fonction achats s’accompagne d’une digitalisation des processus qui vise à gagner en efficience et en fiabilité et à renforcer les liens avec les autres fonctions clés des entreprises (finance, logistique, juridique, etc.). Le marché mondial des solutions d’e-procurement est modérément concentré et concurrentiel, avec de nombreux acteurs de tailles différentes, opérant à l’échelle nationale ainsi que sur le marché international. Le marché est dominé par une dizaine d’éditeurs de logiciels qui se partagent près de 60% des parts de marché. Le leader incontesté du secteur reste le géant allemand SAP-ARIBA, qui détient une part de marché de près de 22% (et ce depuis 2015). 10. https://www.appsruntheworld.com/top-10-procurement-software-editors-and-market-forecast/. CHAPITRE III - ÉTUDE DE MARCHÉ I 45 Schéma 5 : Parts de marché des éditeurs de suites e-procurement en 2019 Exhibit 1: 2019 Procurement applications market shares split by top 10 procurement vendors and others, % SAP Other Oracle Coupa Software Zycus GEP Ivalua Mercateo Infor Jaggaer BasWare Source : auteurs 3.1.2. Profil type des éditeurs de la suite e-procurement Les chiffres présentés ci-dessus sont basés sur une liste publique de 91 éditeurs de systèmes d’e-procurement publiée par le site Appsruntheworld11. La plupart des éditeurs de solutions e-Procurement de cette liste sont originaires d’Amérique du Nord (41 développeurs de SI d’approvisionnement sur 91, soit environ 49%). En deuxième position vient l’Europe (37%), la France étant en tête du continent en termes de nombre d’éditeurs, suivie par l’Allemagne (où se trouve SAP, entreprise leader du marché). La plupart de ces éditeurs ont été créés entre le début des années 1990 et 2010. Après 2010, le nombre de nouveaux fournisseurs a considérablement diminué. Le marché est principalement composé d’éditeurs de taille moyenne à petite, puisque près de 80% d’entre eux ont un chiffre d’affaires inférieur à 50 millions de dollars. Certains des éditeurs affichant un Chiffre D’affaires supérieur sont en fait des filiales de plus grands groupes logiciels. Dans leurs cas, il est parfois difficile d’obtenir des informations exactes sur les effectifs et le chiffre d’affaires relatifs à la seule activité e-procurement. 11. https://www.appsruntheworld.com/cloud-top-500/Procurement/ 46 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Schéma 6 : Informations générales sur le marché Country classification Workforce classification # of e-GP developers per country # of employees per e-GP providers company <20 The United States of America ---- 41 20-100 >500 11% France ---------------------------- 9 Germany -------------------------- 6 9% The United Kingdom -------------- 6 Japan ----------------------------- 3 52% Canada --------------------------- 2 28% Other ---------------------------- 21 100-500 Creation date classification Turnover classification # of e-GP developers per creation date Average annual turnover (2018-20) 2020 and after -------------------- 0 >50 M$ From 2010 to 2020 ---------------- 7 <5 M$ From 2005 to 2010 ---------------- 6 20-50 M$ 21% 0% From 2000 to 2005 --------------- 17 From 1995 to 2000 --------------- 14 50% From 1990 to 1995 --------------- 13 5-20 M$ 29% From 1980 to 1990 --------------- 15 Prior to 1990 --------------------- 17 Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 47 3.1.3. Caractéristiques et tendances du marché Le marché est relativement mature : • Les solutions existantes sont bien conçues, couvrent la plupart des processus d’achat et le coût de conception des fonctionnalités « de base » sont inférieurs à ceux d’il y a 20 ans. Le taux d’équipement des grandes entreprises privées est aujourd’hui assez élevé dans tous les secteurs économiques. Les entreprises sont en effet globalement convaincues de la valeur ajoutée apportée par l’e-procurement pour mutualiser/dématérialiser leurs achats et pour homogénéiser leurs processus. En comparaison, le taux d’adoption de l’e-procurement dans les organisations publiques accuse un retard très important. • La récente crise COVID-19 a accru le besoin de numérisation et a donc augmenté l’appétit pour les suites logicielles Achats/Approvisionnements. Pour rester attractifs, les éditeurs de logiciels doivent aujourd’hui mettre en œuvre des stratégies qui leur permettent de se différencier : 1 Développer une suite complète e-procurement couvrant les processus S2C et P2P.... 2 ... Ou adopter une approche “best of breed” en se spécialisant sur un domaine fonctionnel (exemples : focalisation sur la dimension décisionnelle, sur les « achats directs » dans l’industrie, sur les prestations intellectuelles...) ou en se spécialisant sur un secteur (secteur public, santé, ...). 3 Offrir de fortes capacités d’intégration “prêtes à l’emploi” avec les principaux systèmes ERP et avec les fournisseurs et services de données tiers 4 Améliorer la facilité d’utilisation (exemples : nombre de clics nécessaires pour passer une commande ou créer un projet d’achat, possibilité de rechercher et de consulter rapidement des informations...) 5 Etendre la capacité à personnaliser le logiciel pour « coller » aux processus du client, par le biais d’outils avancés de configuration (par opposition aux activités de “customization”. Veuillez-vous référer à la partie II pour plus de détails sur ce sujet) 6 Intégrer des technologies disruptives comme l’IA (Intelligence Artificielle) afin d’éradiquer les tâches répétitives et à faible valeur ajoutée ou afin de produire des analyses prédictives. La pandémie de COVID-19 et ses conséquences ont accru le besoin de flexibilité et d’agilité en matière d’achat et ont fait émerger de nouveaux besoins. Par conséquent, les éditeurs de logiciels d’e-procurement parient actuellement sur ces technologies de rupture afin de toujours mieux répondre aux attentes clients. 48 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 3.2. Présentation du marché de l’e-GP 3.2.1. Profils des éditeurs d’e-GP Les données ci-dessus - relatives aux éditeurs e-GP - sont tirées de l’étude de marché menée par la Banque Mondiale : • La plupart des fournisseurs sont originaires d’Amérique du Nord et d’Europe. Il y a aussi quelque acteur en Asie. • Certains fournisseurs de cette liste sont des entreprises leaders sur le marché mondial des fournisseurs de suites S2P, avec une expérience pertinente dans le secteur public. Plusieurs entreprises sont des filiales de groupes et communiquent des données consolidées (ce qui explique la proportion relativement élevée d’entreprises ayant un chiffre d’affaires supérieur à 100 millions de dollars et un effectif supérieur à 500 personnes). • En outre, la plupart des entreprises identifiées ont été créées entre 1995 et 2005. Schéma 7 : Informations générales sur les éditeurs e-GP Country classification Workforce classification # of e-GP developers per country # of employees <20 The United States of America -----11 >500 6% 20-100 France ---------------------------- 4 The United Kingdom -------------- 4 36% Canada --------------------------- 2 33% Finland --------------------------- 2 India ----------------------------- 2 25% 100-500 Creation date classification Turnover classification # of e-GP developers per creation date Annual turnover (2018-20) >100 000 M$ <5 M$ 2020 and after -------------------- 0 From 2010 to 2020 ---------------- 5 From 2005 to 2010 ---------------- 5 25% 33% From 2000 to 2005 --------------- 8 From 1995 to 2000 --------------- 8 From 1990 to 1995 --------------- 2 17% From 1980 to 1990 --------------- 5 20-100 000 M$ 25% Prior to 1990 --------------------- 3 5-20 M$ Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 49 3.2.2. Cartographie et positionnement des éditeurs de solutions e-GP Méthodologie Pour réaliser cette étude de marché, différentes sources d’informations complémentaires ont été utilisées : 1 En mettant en commun les bases de données de la Banque Mondiale, 36 éditeurs de logiciels ayant la capacité de fournir des solutions e-procurement pour le secteur public ont été identifiés. 2 Un questionnaire d’étude de marché (veuillez-vous référer à l’annexe 2) a ensuite été bâti autour de différents chapitres clefs : profil de l’entreprise, couverture fonctionnelle, modèle de mise en œuvre, hébergement/sécurité des données et modèles de tarification. 3 Ce questionnaire a ensuite été envoyé aux fournisseurs identifiés. Pour augmenter la visibilité de l’étude de marché, la Banque Mondiale a également publié le questionnaire “ étude de marché “ sur sa plateforme. Les éditeurs disposaient de 6 semaines pour renvoyer le questionnaire renseigné. 4 Le taux de réponse a été de 50% avec 18 questionnaires reçus. Tous les répondants ont présenté leur offre de manière relativement exhaustive et ont fourni de nombreuses informations sur les tendances du marché. Les 18 fournisseurs ayant répondu sont par ordre alphabétique : Atexo, E-Procurement Technologies Limited (ProcureTiger), Bip Solutions, Bonfire, EASIBUY, European Dynamics, Guadaltel, GEP (NB Ventures, Inc.), In-tend Limited, IOS Partners, Inc., Ivalua SAS, Market Dojo Ltd., Nextenders, Neqo, Otwarty Rynek Elektroniczny (Market Planet), ProcurementExpress.com, Synertrade Inc., and uStudio. 5 Les données transmises par les éditeurs ont également été croisées avec les retours d’expérience des gouvernements sur la mise en œuvre de solutions e-GP financées par la Banque mondiale (principalement sur des projets réalisés en Afrique). 6 Enfin, les données ont été croisées avec la base d’information structurée GPPD (Global Public Procurement Database) de la Banque mondiale.12 12. Global Public Procurement Database (GPPD): https://www.globalpublicprocurementdata.org/gppd/ 50 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Cartographie des éditeurs de logiciels e-GP Le graphique ci-dessous résume le positionnement des éditeurs e-GP, selon deux critères : la couverture fonctionnelle et la maturité/l’intérêt vis-à-vis du secteur public. 1. La couverture fonctionnelle correspond au taux de couverture des fonctionnalités e-GP (veuillez-vous référer à la partie I. Introduction). Pour chaque fournisseur, le pourcentage a été calculé en fonction des réponses au questionnaire de l’étude de marché qui ont ensuite été converties en une note de 1 à 10. 2. La maturité/intérêt de l’éditeur d’e-GP à l’égard du secteur public ont également été évalués à partir des réponses au questionnaire, en fonction : • Du nombre de projets réalisés dans le secteur public • Du pourcentage du Chiffre d’affaires réalisé dans le secteur public • De l’importance des fonctionnalités liées à la gestion des marchés publics dans la « roadmap » de l’éditeur Schéma 8 : Cartographie des éditeurs e-GP Solutions ináppropriées Spécialistes e-GP “Généralistes” suite compléte Nextenders IOS Partners Guadaltel European Dynamics 10 Ivalua NEQO Atexo In-tend Jaggaer 9 Maturité et intérêt pour le secteur public Bonfire SAP Ariba 8 EASiBuy Oracle 7 Synertrade Coupa GEP 6 BiP Solutions 5 Basware Corcentric Zycus 4 ProcureTiger 3 uStudio 2 ProcurementExpress.com Marketplanet 1 Market Dojo 0 0 1 2 3 4 5 6 7 8 9 10 Couverture fonctionnelle Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 51 Trois types différents d’éditeur d’e-GP peuvent être identifiés : • Les suites complètes “généralistes” qui couvrent la plupart des fonctionnalités requises mais ne sont pas nécessairement les mieux placés en termes de maturité/intérêt pour le secteur public. La plupart de ces éditeurs de logiciels se sont en effet récemment concentrés sur les besoins du secteur public, qui est désormais considéré comme un important moteur de croissance. Cela ne signifie pas que ces éditeurs de logiciels ne sont pas capables de mener à bien un projet de déploiement d’e-GP pour des organisations publiques. Cela montre plutôt que leur stratégie n’était pas orientée uniquement vers le secteur public à ce stade. Cette catégorie comprend également les modules e-GP des principaux systèmes ERP (voir commentaires spécifiques dans le zoom ci-dessous*). • Les spécialistes e-GP. Ces éditeurs e-GP couvrent moins de « modules » que le groupe précédent, mais ils offrent généralement des fonctionnalités plus avancées dans leurs domaines de spécialisation. Ils ont généralement une maturité/un intérêt majeur pour le secteur public et couvrent les fonctionnalités essentielles d’e-GP (publication des marchés publics, gestion de procédures, gestion et suivi des contrats adaptés au secteur public, etc.). De plus, ces éditeurs e-GP peuvent généralement s’engager plus facilement à intégrer dans leur « roadmap » de nouvelles fonctionnalités jugées pertinentes par un client public si celles-ci font défaut aujourd’hui. • Éditeurs de logiciels de niche. Ces éditeurs de logiciels fournissent des solutions qui ne couvrent qu’une petite partie des fonctionnalités attendues de l’e-GP, et ne visent pas nécessairement les clients publics. *L’ACCENT EST MIS SUR LES MODULES E-GP LIÉS AUX SUITES ERP. Les ERP couvrent plutôt bien les processus “procure-to-pay” (P2P) et transactionnels, ainsi que la gestion des données de référence (produits, articles, etc.). Les ERP sont généralement en retrait en termes de fonctionnalités d’analyse des dépenses, d’e-sourcing et de gestion des informations fournisseurs. On constate également une supériorité de l’expérience client et de la convivialité des outils “best of breed”, notamment en ce qui concerne la recherche d’informations, les catalogues e-procurement et la gestion des « workflows ». Généralement issus des processus « source-to- contract » (S2C), les éditeurs spécialisés dans l’e-procurement se sont développés et proposent désormais des solutions sophistiquées, robustes et stables qui concurrencent les ERP sur le P2P. Les modules S2C des ERP ont en outre tendance à être plus complexes à mettre en œuvre et à maintenir, qu’ils soient dans le Cloud ou hébergés « on-premise ». Leur modèle de données tend à être moins ouvert et leur capacité à configurer les processus d’achat est plus limitée. En outre, même lorsque les ERP ont acquis certaines éditeurs S2C spécialisés pour combler leurs lacunes fonctionnelles, cela n’en fait pas des solutions complètes unifiées, basées sur un code source unique et une base de données unique. Ce “millefeuille” technologique devient une source majeure de complexité dans les phases de Build et de Run. Les données recueillies au cours de l’étude ne permettent pas d’évaluer précisément les conséquences de cette complexité sur les coûts des projets. Cependant, il est communément admis que les projets « e-procurement » structuré autour d’une solution ERP ont un coût projet plus élevé. 52 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 3.2.3 Couverture moyenne des principaux domaines fonctionnels e-GP par le marché Le diagramme ci-dessous présente la couverture fonctionnelle moyenne des fonctionnalités e-GP par les éditeurs étudiés : Schéma 9 : Couverture fonctionnelle, par caractéristique et par phase 0% 50% 100% PHASE DE PRÉ-ATTRIBUTION 86% 1. Programmation des achats en ligne 80% 2. Publication en ligne/Notification 87% 3. Appel d’offres en ligne 89% 4. Evaluation et attribution en ligne 87% 5. Enchères inversées 86% PHASE DE POST-ATTRIBUTION 61% 6. Gestion des contrats 77% 7. E-catalogues 55% 8. Gestion des catalogues 46% 9. Gestion des DA 66% FONCTIONNALITÉS D’APPUI 66% 10. Portail fournisseurs 56% 11. Gestion des fournisseurs 76% 12. Recherches transverses 36% 13. Suivi et rapports 81% 14. Gestion des litiges 40% Source : auteurs 15. Signature électronique 58% 16. Filtres d’intégrité 58% Le domaine fonctionnel le mieux couvert par les éditeurs est la phase de « pre-awarding » (Les modules 1. à 6 dans notre questionnaire d’étude de marché). Plus précisément, les modules publication/notification en ligne, appels d’offres en ligne et l’évaluation en ligne sont ceux pour lesquels les fournisseurs couvrent en moyenne plus de 86% des besoins. Les modules les moins bien couverts par les éditeurs d’e-GP sont ceux liés à la phase « post- awarding », en particulier les fonctionnalités liées aux e-catalogues, les fonctionnalités d’appui et de recherche transverses, la signature électronique et la gestion électronique des litiges). CHAPITRE III - ÉTUDE DE MARCHÉ I 53 3.2.4. Types d’implémentation proposés (SaaS, COTS, personnalisé) Les éditeurs de logiciels ont été invités à préciser le ou les types d’implémentation qu’ils adoptent. La répartition est présentée ci-dessous : Schéma 10 : Types de solutions fournies par les 18 fournisseurs ayant répondu à l’enquête Nombre de fournisseurs pour chaque solution : Important Moyen Faible SaaS 17/18 Custom 9/18 COTS 7/18 Source : auteurs Plusieurs observations peuvent être formulées à ce stade : • Le mode SaaS est considéré par la plupart des répondants comme le plus pertinent pour mettre en œuvre des solutions e-GP. • La moitié des éditeurs de logiciels déclarent qu’ils peuvent réaliser des projets dans différents modes (SaaS et COTS) ou même dans les trois modes de mise en œuvre. Ceci suggère que ces éditeurs de logiciels tendent progressivement vers le modèle SaaS, réputé plus scalaire et avec une meilleure rentabilité. Mais qu’en réalité, ils mettent davantage en œuvre une approche COTS en essayant de réduire les développements spécifiques (« Customization ») afin de converger plus facilement vers un modèle SaaS à terme. • Un seul répondant (proposant les 3 modes d’implémentation) a indiqué que le mode « CUSTOM » était le plus adapté. 54 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Par ailleurs, il est également très intéressant de croiser le mode d’implémentation retenu avec la couverture fonctionnelle : Schéma 11 : Couverture fonctionnelle par types de solutions Custom COTS SaaS 100% 100% 100% 87% 87% Fonctionnalités Fonctionnalités 80% d’appui d’appui Fonctionnalités d’appui Phase de Phase de post-attribution post-attribution Phase de post-attribution Pre- Pre- Pre- awarding awarding awarding phase phase phase Source : auteurs Les modes de mise en œuvre les plus susceptibles de couvrir tous les besoins sont les modes CUSTOM et COTS (87%). Il n’est pas surprenant de constater que les solutions CUSTOM peuvent couvrir très largement Le % de couverture déclaré par les répondants proposant un mode CUSTOM devrait théoriquement être de 100% (si on exclut toute contrainte budgétaire). Le taux de couverture déclaré par les répondants pratiquant le mode CUSTOM peut donc illustrer une attitude prudente face à la complexité de certaines fonctionnalités e-GP notamment sur les fonctionnalités relatives aux catalogues et aux processus P2P (fonctionnalités 7-8-9 dans notre grille d’analyse. Veuillez- vous référer à l’annexe 2. CHAPITRE III - ÉTUDE DE MARCHÉ I 55 3.2.5. Mise en œuvre de la solution e-GP en Afrique 3.2.5.1. Capacité de déploiement en Afrique Tous les répondants ont déclaré qu’ils étaient en mesure de déployer leur solution en Afrique, sans pour autant avoir un bureau sur le continent. Schéma 12 : Capacité à mettre en œuvre une solution e-GP en Afrique 100% des fournisseurs ayant Fournisseurs ayant Fournisseurs avec répondu (18/18) déclarent qu’ils sont une présence physique partenaire certifié capables de s’implanter en Afrique en Afrique (bureaux) en Afrique Oui Oui 1 Oui 7 18 Non 11 17 Non Source : auteurs Dans une certaine mesure, ces réponses ne sont pas très surprenantes car la plupart des tâches liées à l’intégration des logiciels peuvent être effectuées à distance. Environ 25% des répondants déclarent qu’ils peuvent déployer des ressources fonctionnelles sur place, même sans avoir de bureaux sur le continent africain (ressources voyageant depuis l’Europe ou depuis le continent américain). Les ressources plus techniques sont généralement situées dans les bureaux de R&D. La plupart des éditeurs de logiciels déclarent qu’ils ne déploient des ressources techniques sur site « client » que lorsque cela est nécessaire. Un autre sujet important est la capacité à mobiliser un partenaire certifié en Afrique (au moins pour les modes COTS et SaaS comme décrit dans la partie II.). Un partenaire certifié est une entreprise habilitée par l’éditeur à la mise en œuvre de son logiciel. La certification implique notamment que les ressources clefs soient formés et passent des examens d’habilitation au paramétrage de la solution. 63% des éditeurs de logiciels interrogés ont un ou plusieurs partenaire(s) certifié(s) en Afrique. Ces partenaires sont soit de grandes sociétés de conseil informatique généralistes présentes en Afrique (EY, Capgemini, Accenture, etc.), soit des intégrateurs e-GP spécialisés, soit des sociétés de conseil ayant une connaissance des marchés publics et/ou de la culture locale. Parmi les éditeurs de logiciels qui nous ont répondu, plusieurs ont déjà réalisé des projets pour des organismes publics africains, et dans certains cas, ont déjà déployé l’e-GP d’un gouvernement africain (exemples de ces réponses : déploiement de l’e-GP en Zambie, en Tanzanie, en Ouganda, au Gabon, au Nigeria, etc.). 56 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 3.2.5.2. Répartition préférentielle des rôles pour les projets e-GP Les réponses au questionnaire font apparaître trois répartitions des rôles « type » : Schéma 13 : Trois répartitions des rôles entre les acteurs Editeur de Editeur sans Intégrateur de 1 services complets 2 effectif d’exécution 3 services complets INTEGRATEUR INTEGRATEUR Editeur Editeur certifié certifié ou CLIENT Design, Design, Design & Build Run Build & Run Build & Run Source : auteurs Dans le premier type, “service complet”, l’éditeur de logiciels est responsable de l’intégration complète du logiciel et de sa maintenance applicative. 72% des éditeurs de logiciels interrogés précisent qu’ils peuvent réaliser eux-mêmes les différentes phases des projets e-GP (Design, Build et Run), sans recourir à l’assistance d’un intégrateurs tiers. Ils déclarent disposer des ressources nécessaires pour mener à bien les projets e-GP. Ils mentionnent généralement que l’intervention de consultants fonctionnels tiers est souvent nécessaire pour guider la phase de Design. Les éditeurs « service complet » déclarent néanmoins pouvoir aussi travailler avec un intégrateur, si le client l’exige le cas échéant (volonté de réduire la dépendance vis-à-vis de l’éditeur de logiciels). Pour certains de ces répondants, le client peut aussi décider d’internaliser la maintenance de l’application sous certaines conditions (Run). Le deuxième type, “Editeur en build et intégrateur en run”, correspond au cas où la plus grande partie de la charge de travail de projet est gérée par l’éditeur de logiciels, tandis que le support et la maintenance de l’application en vie courante sont délégués à un intégrateur tiers. 20% des éditeurs de logiciels interrogés déclarent qu’ils font systématiquement appel à des intégrateurs pour la phase de Run (pour le support applicatif de niveau 1 et 2) ou qu’ils font appel à l’intégrateur dans des situations spécifiques. . CHAPITRE III - ÉTUDE DE MARCHÉ I 57 Dans la troisième répartition des rôles, “intégrateur service complet”, l’éditeur de logiciels laisse la gestion de toutes les phases du projet (Design, Build, run) à un intégrateur certifié. L’intégrateur gère les phases de Design et de Build. Dans la phase Run, l’éditeur de logiciel sera uniquement sollicité pour des anomalies majeures ou des demandes d’évolution nécessitant un travail sur le code source. Ce modèle est plutôt rare et indique un certain degré de maturité car il exige des processus complexes et un réseau d’intégrateurs suffisamment expérimentés. Plus un éditeur de logiciels se développe, plus il tend vers ce modèle. Parmi les répondants au questionnaire de cette étude, seul un éditeur de logiciels a déclaré travailler exclusivement sur ce modèle. 16 répondants déclarent pouvoir gérer eux-mêmes la phase de Design et de Build. 1 répondant fait systématiquement appel à un intégrateur certifié, et autre travaille en collaboration avec un intégrateur dans la majorité des cas. En outre, 14 répondants déclarent pouvoir gérer eux-mêmes la phase de Run. 2 répondants font systématiquement appel à un intégrateur certifié. 2 autres répondants s’appuient sur des ressources mixtes (ressources internes et celles d’un intégrateur). Dans tous les cas, la répartition des responsabilités entre l’éditeur du logiciel, l’intégrateur et le gouvernement est définie dans une matrice d’alignement des responsabilités (Ex : matrice de type RACI) qui est jointe au Service Level Agreement (SLA). Schéma 14 : Analyse de la distribution des rôles de mise en œuvre Effectifs pour la phase de Build Effectif pour la phase de run N/A Intégrateur certifié Intégrateur certifié 1 1 Mixte 2 2 16 14 Editeur Editeur Nombre de fournisseurs par modèle de répartition des rôles Intégrateur de services complets Editeur sans effectif d’éxecution 1 3 13 Editeur de services complets Source : auteurs 58 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 3.2.5.3 Planning type de la mise en œuvre d’une solution e-GP La plupart des éditeurs de logiciels estiment que les phases de Design et de Build durent entre 6 mois et 1 an pour le périmètre à l’étude. Les durées estimées des solutions CUSTOM sont généralement beaucoup plus longues. Bien entendu, cette analyse de la durée du projet de déploiement basée sur les réponses reçues de l’enquête présente des limites. Il est en effet très compliqué pour un fournisseur d’estimer la durée d’un projet de déploiement sans avoir pris connaissance au préalable des spécifications techniques. Schéma 15 : Estimation du temps de mise en œuvre par type d’éditeur de logiciels Type d’éditeur Caractéristiques Durée de déploiement Spécialiste e-GP • Solution la moins configurable Moins de 6 mois Solutions à portée limitée • Fonctionnalités très spécifiques Généraliste suite • Solutions configurables Entre 6 mois complète • Solutions couvrant l’ensemble du périmètre fonctionnel et 1 an • Solutions 100% configurables, adaptables à tous les besoins et tailles d’entreprises Suite e-GP complète • Il est possible de choisir entre un large éventail de Plus d’un an fonctionnalités disponibles couvrant l’ensemble du champ d’application en profondeur Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 59 3.2.6. Hébergement et sécurité des données 3.2.6.1. Hébergement sur site et hébergement hors site Tous les États africains ayant répondu à notre matrice de collecte de données indiquent avoir opté pour un hébergement sur site (« on premise ») pour leur solution e-GP. Nous avons donc cherché à connaître les capacités des différents répondants en matière d’hébergement des données. Sur la base des réponses reçues, il est possible d’observer les tendances suivantes : 1. L’hébergement sur site (« on premise ») n’est pas le modèle de choix pour les éditeurs de SaaS et COTS, car cette modalité d’hébergement implique de baisser la qualité de service : a. Il est plus difficile pour les éditeurs de logiciels de reproduire les anomalies, de les corriger et de fournir des correctifs. b. L’éditeur du logiciel ne maîtrise plus complétement ses délais de réponse. c. Il est plus difficile de garantir le bon fonctionnement de certains modules. d. Cette modalité d’hébergement nécessite la mise en place de processus spécifiques, ce qui représente des coûts supplémentaires. 2. Les éditeurs de logiciels peuvent accepter de considérer un hébergement « on-premise » dans certains cas. 66% des répondants sont prêts à l’envisager et 44% des éditeurs de logiciels interrogés l’ont déjà pratiqué avec certaines conditions. Afin d’arbitrer cette question, les éditeurs semblent considérer deux questions : a. Les perspectives de revenus avec le client sont-elles jugées suffisantes ? b. Existe-t-il un cadre réglementaire spécifique qui exige un mode « on-premise » ? Avant de prendre cette décision, les éditeurs de logiciels apprécient rencontrer les équipes techniques des clients. Ce type de discussion n’est pas toujours facile à organiser pendant la phase d’appels d’offres. Les phases de sourcing (en amont de la publication) peuvent être mises à profit pour dialoguer avec les fournisseurs sur leur capacité en matière d’hébergement. Christina Wocin 60 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Schéma 16 : Expérience et acceptation des éditeurs de logiciels interrogés en matière d’hébergement « on premise » Les éditeurs qui n’ont jamais mis en œuvre leur solution sur site et n’envisagent pas de le faire 6 Les éditeurs qui ont déjà mis en œuvre leur solution sur site 10 Les éditeurs qui n’ont jamais mis en œuvre leur solution sur site mais qui envisageraient de le faire 2 Source : auteurs Dans le cas d’un hébergement « on premise », le client devient entièrement responsable de la sécurité des données et de l’administration technique des serveurs. Les répondants insistent particulièrement sur ce point. La plupart des répondants indiquent aussi qu’ils revoient aussi à la baisse les engagements de niveau de service, notamment en ce qui concerne les délais de correction des anomalies. 3.2.6.2. Présentation des solutions d’hébergement de données Sur les 18 éditeurs de logiciels ayant répondu, seuls 3 disposent de leurs propres centres de données. Les autres éditeurs de logiciels font appel à des prestataires de services d’hébergement de données. CHAPITRE III - ÉTUDE DE MARCHÉ I 61 Schéma 17 : Hébergement des données : hébergement sur site ou hors site 15 3 Hébergement externe Centres données des fournisseurs E-GP (BIP solution Ltd, European Dynamic, In-tend Limited) Source : auteurs Schéma 18 : Les principaux prestataires d’hébergement utilisés par les éditeurs e-GP Clever Cloud OVH Noris Network 1 2 Orange 1 1 Google Cloud Platform 1 Amazon Web Services 4 Aptum Technologies 1 Telehouse 1 Echinix 1 1 CtrlS Data Center 2 Rackspace 4 Microsoft Azure Data Centers Source : auteurs Nous constatons que la plupart des répondants utilisent des « data centers » en Europe ou aux États-Unis. Aujourd’hui, il existe en Afrique très peu de sociétés spécialisées dans l’hébergement de données qui soient suffisamment grandes et fiables pour pouvoir héberger les données traitées dans un système e-GP. 62 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Schéma 19 : Nombre de développeurs e-GP pour chaque entreprise de services d’hébergement Fournisseur de services d’hébergement de données principalement utilisé par les éditeurs de logiciels e-GP Localisation des services d’hébergement OVH • France Amazon web services (AWS) • États-Unis, Brésil, Royaume-Uni, Chine, Japon, Australie. CtrlS Data center • Inde Microsoft Azure Data centers • États-Unis, Mexique, Canada, Brésil, Europe (France, Allemagne, Royaume-Uni, Autriche, Pologne, Espagne, Inde, Chine, Japon, Australie, Afrique du Sud, etc. Rackspace • États-Unis, Royaume-Uni, Russie, Chine, Australie Equinix • États-Unis, Europe (France, Royaume-Uni, Allemagne, Italie, Espagne, etc.), Moyen- Orient, Chine, Japon, Singapour, Australie Telehouse • États-Unis, France, Chine, Singapour, Royaume-Uni, Japon, Turquie. Aptum technologies • États-Unis, Canada, Royaume-Uni Google Cloud Platform • États-Unis, Canada, Brésil, Royaume-Uni, France, Allemagne, Espagne, Italie, Pays- Bas, Moyen-Orient, Inde, Chine, Japon, Taiwan, Singapour, Indonésie, Australie Orange • France Noris Network • Allemagne Schéma 20 : Nombre de fournisseurs de solutions hébergeant des données sur chaque continent 12 12 10 8 9 6 4 2 2 0 0 0 0 Amérique Europe Asie Amérique Afrique Océanie du Nord du Sud Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 63 3.2.4.3. Hébergement et sécurité des données Tout d’abord, il convient de faire la distinction entre les solutions SaaS « multi-tenant » et « single-tenant ». En informatique, le terme multi-tenant, ou multi-entités, désigne un principe d’architecture logicielle qui permet à un logiciel de servir plusieurs organisations clientes à partir d’une seule installation. Il s’oppose à une architecture multi-instance (ou « single-tenant ») où chaque organisation cliente dispose de sa propre instance d’installation du logiciel. Potentiellement sur une application multi-tenant, les failles de sécurité sont plus importantes en cas d’erreur dans le code. Le principal risque est qu’un utilisateur trouve une faille pour accéder aux données d’autres clients sur le même serveur. Il est donc recommandé de s’orienter vers des solutions “single- tenant” pour les solutions e-GP. Tous les éditeurs de logiciels ne proposent pas une architecture “single-tenant”, et ce point doit être évalué lors du processus de sélection. La plupart des éditeurs de logiciels ou des sociétés d’hébergement auxquelles ils font appel en sous-traitance certifient leurs services pour prouver leur qualité. Tous les fournisseurs de services d’hébergement externes utilisés par les développeurs e-GP interrogés possèdent une ou plusieurs certifications. Les certifications les plus fréquentes sont : (i) ISO27001, “Management de la sécurité de l’information”. (ii) ISO 9001, “Gestion de la qualité”. (iii) SOC 1, (iv) SOC 2. Lorsqu’ils sont interrogés sur leur politique de protection des données, les éditeurs de logiciels se réfèrent le plus souvent aux exigences des contrats qui les lient aux fournisseurs de « data centers ». En matière de sécurité physique des serveurs, il existe des pratiques communes, tant chez les éditeurs de logiciels disposant de leurs propres centres de données que chez ceux faisant appel à des hébergeurs tiers. Parmi les plus couramment citées par les répondants, citons : • S’assurer que la conception du bâtiment est sécurisée (pas de fenêtres, nombre limité d’entrées, escaliers de secours sans prise sur l’extérieur du bâtiment, épaisseur des murs, barrières diverses pour limiter la circulation des véhicules autour du bâtiment). • Surveillance et accès limité au centre de données et aux serveurs physiques. Les centres de données sont étroitement surveillés, avec des agents de sécurité permanents, une surveillance vidéo du bâtiment lui-même et, dans la plupart des cas, de ses environs. Pour éviter toute intrusion, les accès sont contrôlés : badges sans contact, systèmes de reconnaissance biométrique, accompagnement permanent des visiteurs par un employé du centre de données. • Contrôle de la température : les centres de données doivent être maintenus à une température constante tout au long de l’année. C’est pourquoi ils intègrent des systèmes de refroidissement avancés qui empêchent les serveurs de fluctuer en température.Dispositif de prévention des incendies : le centre de données doit être protégé contre les incendies. Il existe généralement deux types d’alarmes : celle qui détectera un départ de feu potentiel et l’arrêtera, et celle qui activera les dispositifs de sécurité incendie, comme les portes coupe- feu par exemple. De nombreux fournisseurs de services d’hébergement créent également une copie des données hébergées pour un client dans un autre centre de données, afin de garantir la récupération des données en cas de sinistre. • Certains centres de données offrent également le cryptage des données au niveau du serveur, ce qui rend les données inaccessibles à toute personne ayant un accès physique aux centres de données. 64 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 3.2.4.4 Sécurité des applications L’étude de marché souligne que la plupart des éditeurs de logiciels SaaS e-GP mettent en œuvre des politiques de sécurité et disposent de processus de sécurité très stricts. Certains répondants déclarent effectuer des revues de code par des organismes indépendants avant la sortie de chaque nouvelle version (afin de vérifier que de nouvelles vulnérabilités n’ont pas été créées). 15 répondants ont déclaré que leur code source était audité sur une base annuelle par une société tierce. Les éditeurs de logiciels les plus avancés effectuent également des tests de pénétration avec le système des 3 boîtes : boîte noire (les testeurs ne connaissent rien de l’application et tentent de s’y introduire par tous les moyens), boîte grise (un utilisateur inscrit sur l’application tente de trouver une faille pour acquérir de nouvelles autorisations), boîte blanche (le testeur a accès au code et identifie les failles de sécurité dans les différentes couches du code). Certains éditeurs e-GP disposent même d’équipes dédiées à la sécurité applicative. Schéma 21 : Editeurs faisant auditer leur application sur una base annuelle Non 3 25 Oui Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 65 3.2.5. Modèle financier du fournisseur 3.2.5.1. Types de modèles financiers La plupart des éditeurs d’e-GP fonctionnent généralement avec un modèle financier qui combine un abonnement (par exemple : annuel, ou calculé sur une base trimestrielle, etc.) et un modèle de licence. Schéma 22 : Nombre de fournisseurs par modèle financier Modèle d’abonnement uniquement N/A 2 1 Modèle de licence uniquement 6 Autre 8 8 A la fois abonnement et licence Source : auteurs 3.2.5.2. Modèles de tarification Il existe deux types de modèles de tarification : 1. Des modèles de tarification simplifiés, basés sur un seul paramètre. Il s’agit soit du nombre d’utilisateurs, soit du nombre d’appels d’offres gérés par le client sur la plateforme. Ces deux paramètres sont probablement ceux qu’un gouvernement peut le plus facilement estimer. L’avantage de ce premier modèle est donc sa simplicité et sa prévisibilité. 2. Modèles avec une combinaison de plusieurs paramètres. a. La combinaison est principalement composée par le nombre d’appels d’offres plus le nombre de contrats et/ou de bons de commande gérés dans l’outil. Ces deux paramètres sont liés aux stratégies d’achat déployées par le client (allotissement, nombre d’accords- cadres, groupement de commandes, etc.) et sont donc plus difficiles à prévoir. b. Les combinaisons qui prennent en compte le nombre de fournisseurs sont assez rares. Seuls 10% des éditeurs d’e-GP interrogés génèrent des revenus à partir des fournisseurs qui soumettent des offres par le biais de la solution. L’un de ces deux éditeurs d’e-GP propose même un modèle sans frais pour l’organisme acquéreur, l’intégralité du coût du logiciel étant supportée par les commissions/droits de participation perçus auprès des éditeurs d’e-GP. c. En plus de s’appuyer sur les “objets métiers”, certains modèles ajoutent des facteurs de prix plus techniques comme la quantité de données stockées ou la puissance de calcul nécessaire. Pour simuler le coût d’acquisition, le gouvernement doit donc être en mesure de convertir les objets « métier » en unités d’œuvre informatiques. Il s’agit certainement du modèle de tarification le moins transparent et le moins prévisible. Cette combinaison semble être utilisée principalement par les éditeurs d’e-GP dont le métier d’origine est la fourniture de plateformes de publication d’appels d’offres. 66 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Il existe donc une relative diversité de modèles de tarification. Afin de garantir une concurrence de qualité, il est donc important des données précises sur : • Le nombre d’utilisateurs « cibles ». On considère généralement 2 types d’utilisateurs : les “full-users” (qui ont des droits avancés) et les “read-only users” (qui ont des droits limités généralement en mode « consultation) • Le nombre de fournisseurs enregistrés sur le futur système • Le nombre d’appels d’offres gérés • Le nombre de contrats gérés • Le nombre de bons de commande • Eventuellement, une estimation de la quantité de données stockées et de la puissance de calcul requise Schéma 23 : Modèles de tarification Quantité de Puissance # d’utilisateurs # de # d’Appels # de # de bons de données de calcul internes fournisseurs d’Offres contrats signés commande stockées utilisée Atexo BiP Solutions Bonfire EASiBuy ProcureTiger European Dynamics GEP Guadaltel In-tend IOS Partners Ivalua Market Dojo NEQO Nextenders Marketplanet ProcurementExpress Synertrade uStudio Source : auteurs CHAPITRE III - ÉTUDE DE MARCHÉ I 67 3.2.5.2. Coûts des licences estimés par les répondants sur le périmètre d’étude Sur la base du périmètre fonctionnel étudié, les éditeurs de logiciels ont estimé le coût des phases de Design et de Build et le montant des licences. Le schéma ci-dessus présente les montants moyens, minimums et maximums estimés par les fournisseurs qui ont répondu au questionnaire de l’étude de marché. Schéma 24: Montants estimés Coût de la mise en œuvre de la solution e-GP, selon les fournisseurs (K$) Licenses (K$/year) Phase de Design & build (K$) Moyenne 265 197 Min 150 90 SaaS Max 478 300 Médiane 240 200 Moyenne 220 121 Min 100 90 COTS Max 350 175 Médiane 200 110 Moyenne 0 N/A Min 0 N/A Custom Max 0 N/A Médiane 0 N/A Source : auteurs Chapitre IV Analyse coûts-avantages TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 69 Chapitre IV Analyse coûts-avantages 4.1. Modèles de coûts CUSTOM, COTS et SAAS 4.1.1. Méthodologie 4.1.1.1. Hypothèses et conventions Le modèle de coût a été construit sur la base des hypothèses suivantes : • Un cycle de vie de 5 ans • Le champ d’application fonctionnel ci-dessous : PERIMETRE e-GP 1. Programmation des achats en ligne   2. Publication/Notification en ligne   3. Appel d’offres en ligne   4. Evaluation et attribution en ligne   11. Gestion des litiges   13. Suivi et rapports Les indicateurs clés ci-dessous : • Utilisateurs intensifs (création d’appels • Appels d’offres (par an) : 1500 • 20 Ministères d’offres...) : 250 • Lecteurs et validateurs : 1000 • Fournisseurs : 5000 70 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Le modèle est basé sur les données suivantes : • Les coûts des projets (phases de Design et de Build) proviennent de l’étude de marché et ont été ajustés à l’aide des données provenant de l’enquête terrain menée auprès de 54 pays africains : • Budgets de mise en œuvre : • Projets COTS et SaaS : le budget de mise en œuvre (hors interface et gestion du changement) est celui fourni par les éditeurs de logiciels dans l’étude de marché sur le périmètre fonctionnel étudié • Pour les projets CUSTOM, le budget de mise en œuvre a été estimé en croisant 2 méthodes : • Analyse des réponses dans le cadre de l’étude de marché • Calcul d’un budget cible à partir de projets existants et d’une approche comparative des périmètres fonctionnels (définition des multiplicateurs de complexité entre les projets échantillonnés et le périmètre d’étude) • Un budget d’interfaçage type a été calculé avec un expert • Pour les projets CUSTOM et COTS : un expert réseau a estimé le coût de l’infrastructure d’hébergement « sur site » • Les budgets ont ensuite été divisés en différentes composantes de coût (conception, configuration, personnalisation, tests, interfaces et gestion du changement) selon des ratios types utilisés sur les projets informatiques « progiciels » • Le modèle prévoit un poste budgétaire de 300K$ pour réaliser les opérations de communication/sensibilisation dès le début du projet et pour mettre en œuvre les différentes vagues de formation. Ce budget est légèrement inférieur pour les solutions SaaS car l’effort de conception des supports de communication/formation est moindre (adaptation des supports de communication/formation existants) • La durée type des modes de mise en œuvre est la durée théorique annoncée par les éditeurs du logiciel pour les 3 modes de mise en œuvre • Les coûts récurrents (Run) sont issus de l’étude de marché et ont été retraités avec certaines données issues de l’enquête auprès des pays africains : • Licences COTS et SaaS : montants moyens fournis par les éditeurs de logiciels • Coûts annuels d’hébergement pour les projets CUSTOM et COTS : évaluation du coût des services de gestion, de sécurité et de sauvegarde fournis par un expert en réseau. • Coûts de maintenance, d’administration technique et fonctionnelle selon les ratios types utilisés dans la gestion des projets informatiques. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 71 4.1.1.1. Inducteurs de coûts et scénarios de cas connexes CLes facteurs de coûts ayant un impact sur les éléments de coûts mentionnés ci-dessus ont été définis. L’objectif est de simuler l’impact économique d’événements “indésirables” fréquemment rencontrés sur les projets informatiques : • (Problèmes de gouvernance ayant un impact direct sur la durée du projet et donc sur les coûts de gestion du projet 13 • (Manque de connaissance des processus et faible capacité à spécifier/valider les besoins, ce qui conduit à un pourcentage de réalisations qui doivent être abandonnées puis reconstruites • Difficultés d’interfaçage avec les systèmes d’information existants Ces différents facteurs de coût ont été regroupés en 3 scénarios : • Scénario “théorique” : cas d’un projet sans événements imprévus et indésirables. • Scénario “Cas d’usage”, qui comprend un certain nombre d’événements indésirables affectant les éléments de coût. • Scénario “ dégradé “ qui simule un projet présentant plusieurs difficultés/événements indésirables, des changements majeurs affectant l’organisation des achats/marchés publics et nécessitant une refonte importante de certaines fonctionnalités ou règles de gestion lors du Build & Design. 4.1.2. Comparaison des modèles de coûts des différents modes de mise en œuvre selon les 3 scénarios 4.1.2.1 Coût des phases de Design et de Build La modélisation des coûts met en évidence les résultats suivants : • IDans le scénario médian (« cas d’usage »), les projets CUSTOM coûtent environ 2,5 fois plus que le budget de mise en œuvre requis pour les solutions SaaS/COTS. Schéma 25 : Budget de Design et de Build par type de mise en œuvre (K$) - Cas d’usage 2000 1500 1882 1000 783 707 500 Custom COTS SaaS 0 13. https://www.objectstyle.com/agile/software-projects-failure-statistics-and-reasons. 72 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Les projets CUSTOM ont également une plus forte tendance à dériver d’un point de vue budgétaire. • La différence du budget “Design & Build” entre le cas théorique et le scénario « Cas d’usage » reflète les défis classiques rencontrés dans les projets informatiques (nécessité de «reprendre » certaines réalisations, difficultés de validation…). Dans le cas des projets CUSTOM. La différence du budget “Design & Build” entre ces scénarios est de 22%. Dans le scénario où les difficultés du projet s’intensifient (« Cas dégradé »), la dérive budgétaire s’accentue avec un budget supérieur de près de 60% au budget “théorique”. • Dans les projets SaaS ou COTS, l’écart budgétaire entre le « cas théorique » et la « cas dégradé » est plus faible. Schéma 26 : Impact des inducteurs de coûts sur le budget “Design & Build”. Variation du budget des phases de Design & Build en fonction des scénarios. Cas théorique Cas d’usage Cas dégradé 2600 2406 2200 1882 1800 1400 1537 Custom 993 1000 COTS 783 930 600 713 580 SaaS 707 200 Le modèle de coûts montre que les facteurs sélectionnés ont un impact plus important sur les budgets CUSTOM : • En raison de délais de réalisation plus longs qui impactent mécaniquement certains coûts, comme les coûts de gestion de projet (ressources internes et externes mobilisées pour gérer l’avancement des différentes équipes, par exemple). Les projets sur mesure nécessitant beaucoup plus d’efforts, tout allongement du calendrier a un impact fort sur le coût du Design & Build. • Les projets CUSTOM sont très sensibles aux ajustements. Chaque modification en cours de projet est compliquée à gérer et nécessite un processus complet de développement logiciel (spécification, développement, tests unitaires, tests d’acceptation). Dans le cas d’un projet SaaS ou d’un projet CUSTOM avec une quantité raisonnable de développement spécifique, il est beaucoup plus facile de gérer les ajustements pendant le projet. Le coût d’ajustement sera inversement proportionnel aux capacités de configuration du logiciel choisi. • Les difficultés de validation et de prise de décision ont un impact plus important sur les projets CUSTOM, étant donné le nombre d’acteurs/expertises différents à coordonner (voir description au chapitre II). CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 73 • Enfin, les projets CUSTOM offrent moins de flexibilité en termes de gestion d’équipe. Ils rendent plus difficile l’adaptation des ressources/moyens engagés en fonction de l’avancement du calendrier du projet. Par exemple, lorsque des décisions importantes concernant le projet sont mises en attente, il est difficile pour le gouvernement de démobiliser l’équipe projet. Le risque est de déstabiliser une partie de la chaîne de production et de rendre les ressources indisponibles au moment où il faut relancer l’activité. Dans le cas de projets SaaS / COTS, il est plus facile de trouver un accord avec l’éditeur de logiciel / intégrateur pour reporter son intervention (par exemple pour retarder la mise en production d’un module) : les ressources temporairement désengagées sont généralement investies sur d’autres projets gérés en parallèle par l’éditeur de logiciel et les situations de “ stop and go “ sont beaucoup plus faciles à gérer car il y a moins de sujets techniques à gérer en parallèle. • L’enquête terrain a montré une tendance à sous-estimer le budget nécessaire à l’effort de gestion du changement. Par exemple, les représentants tunisiens interrogés ont déclaré que les coûts de gestion du changement et de communication avaient été sous-estimés dans le budget initial, ce qui a considérablement ralenti le déploiement. La modélisation montre également que la durée du projet dans le « cas dégradé » est deux fois plus longue que dans « le cas théorique » (voir le graphique ci-dessous). Schéma 27 : Planification des phases de Design et de Build par scénario Sensibilité du planning projet aux inducteurs du projet Cas théorique Cas d’usage Cas dégradé 30 27 25 to m Cus 20 17 15 C OT S 18 12 12 13 10 8 SaaS 6 9 5 0 Dans le scénario le plus pessimiste, le calendrier de “Design et Build” des projets CUSTOM passe à 27 mois, tandis que le calendrier COTS/SaaS passe respectivement à 18 et 13 mois. Il est intéressant de noter que la durée moyenne des phases de “Design & Build” pour les projets CUSTOM (ou COTS avec un haut degré de personnalisation) parmi les pays africains interrogés est de 25 mois. Cette durée moyenne observée correspond donc au scénario « dégradé » de notre modèle. Nous pouvons donc conclure que le « cas dégradé » est très répandue dans les projets e-GP réalisés en Afrique ces dernières années. 74 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 4.1.2.2 Coûts totaux sur 5 ans (Design, Build et exploitation) En ce qui concerne les coûts totaux (y compris les coûts récurrents) sur 5 ans, les conclusions de la modélisation financière sont les suivantes : • Dans le scénario « cas d’usage », le coût total des projets CUSTOM e-GP sur 5 ans est en moyenne 60% plus élevé que pour les projets SaaS, et en moyenne 25% plus élevé que pour les projets COTS (avec une quantité raisonnable de développement spécifique). Schéma 28: Coûts cumulés de possession de l’e-GP sur 5 ans par type de mise en œuvre Budget total sur 5 ans et sensibilité aux inducteurs (K€) (Budget l’année N) Cas théorique Cas d’usage Cas dégradé 5,000 4,975 4,500 4,203 4,000 to m Cus 3,647 3,643 3,500 3,367 C OT S 3,242 3,000 2,916 2,640 S aa S 2,500 2,467 • Les coûts de gestion de la maintenance corrective, de l’infrastructure technique et des différentes couches de la solution sont plus élevés dans le mode CUSTOM/COTS que dans le mode SaaS. Dans le cas des projets CUSTOM, ces coûts élevés effacent l’avantage “ concurrentiel “ induit par l’absence de licences d’utilisation. Par exemple, le coût de mise en place et de gestion de l’infrastructure technique avec un hébergement “ sur site “ représente à lui seul entre 9 et 10% du coût total de possession de la plateforme e-GP. • Les solutions CUSTOM et COTS (avec une proportion importante de développements spécifiques) sont généralement plus coûteuses à maintenir et à administrer d’un point de vue fonctionnel. Les solutions SaaS/COTS (avec une faible proportion de développements spécifiques) disposent de modules d’administration éprouvés par l’ensemble des clients. Ces clients ont poussé au développement de fonctionnalités permettant des gains de productivité lorsqu’il s’agit de réaliser CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 75 des opérations simples comme la modification de l’habilitation d’un utilisateur ou des opérations plus complexes comme la modification des acteurs ou des règles d’un workflow. Ce type de fonctionnalité “ back-office “ est généralement moins avancé dans les solutions CUSTOM qui n’ont pas été enrichies par le retour d’expérience de multiples clients. Par ailleurs, dans les projets SaaS/COTS, les coûts helpdesk et de support de niveau 1 sont répartis entre les clients, alors que les projets CUSTOM supportent 100% des coûts de support fonctionnel dédiés au projet. • Les mises à jour sont également plus coûteuses dans les modèles CUSTOM ou COTS (avec une grande proportion de développement spécifique). Toute modification est plus difficile à gérer et nécessite une boucle complète de développement logiciel comme dans la phase “Design & Build” (spécification, développement, tests unitaires, tests d’acceptation). 4.1.3. Modèle de coûts appliqué à l’ensemble du périmètre fonctionnel de l’e-GP Les conclusions ci-dessus seraient probablement encore plus marquées si l’analyse des coûts était menée sur l’ensemble du périmètre fonctionnel d’e-GP. En effet, plusieurs fonctionnalités complexes n’ont pas été incluses dans le modèle de coût comme la gestion des DA/Commandes, la gestion des catalogues ou encore la signature électronique. Tous ces domaines nécessitent des règles de gestion complexes. De plus, ces fonctionnalités nécessitent également des écrans très faciles à utiliser et extrêmement bien pensés. Enfin, elles nécessitent une capacité d’interface importante pour être optimisées. Liste des modules non considérés dans l’analyse: 5. Enchères inversées 6. Gestion des contrats 7. E-catalogues 8. Gestion des catalogues 9. Gestion des DA/Commandes 14. Gestion des litiges 15. Signature électronique 16. Filtres d’intégrité Une étude comparative entre la complexité fonctionnelle et d’interfaçage du périmètre étudié celle du périmètre “ mis de côté “ a été réalisée. Il en ressort que la mise en œuvre de l’ensemble des fonctionnalités serait 2,5 fois plus complexe que sur le périmètre étudié. Schéma 29 : Complexité du projet par portée 100 80 x 2,5 60 60,2 100 40 39,8 20 BCR 0 Périmètre étudié Périmètre non étudié Champ d’application complet 76 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 4.2. Analyse BCR Les “Benefits Costs Ratios” (BCR) ont ensuite été calculés afin de comparer le retour sur investissement des différents types de mise en œuvre. Le ratio BCR permet de résumer l’intérêt d’un investissement en divisant la valeur actuelle des bénéfices attendus par la valeur actuelle des coûts générés. C’est un ratio largement utilisé pour comparer l’intérêt relatif de différents projets d’investissement. Nous l’avons utilisé ici pour comparer l’intérêt de l’investissement sur les 3 modes de mise en œuvre selon la formule suivante : BCR Où : BCR = « Benefit-Cost Ratio » PV = « Present Value » = Valeur actuelle CF = « Cash Flow » = Flux de trésorerie d’une période (classé respectivement comme bénéfice et coût) i = « Discount Rate » = Taux d’actualisation de 5 % N = « Total Number of Periods” = Nombre total de périodes t = « Period in which the Cash Flows occur » La « PV » des coûts, c’est-à-dire la valeur actuelle des coûts est basée sur les données de la modélisation financière détaillée dans le chapitre précédent. Concernant la « PV » (la valeur actuelle) des bénéfices, nous avons supposé que les 3 modes de mise en œuvre produisent les mêmes effets économiques selon les hypothèses suivantes : • Globalement, les dépenses liées aux marchés publics représentent en moyenne 13 % à 20 % du PIB selon le GPPD de la Banque mondiale. Nous avons considéré la fourchette basse par précaution. • Montant “traité” annuellement = montant des dépenses publiques effectivement renégociées chaque année = 1/3 du montant des dépenses de marchés publics habituellement renégociées chaque année. • Calcul des effets économiques, inspiré des méthodes utilisées dans certains pays pour fixer des objectifs de gains réalisés dans le cadre de projets de transformation transversaux (mise en place de nouveaux leviers, agrégation de la demande et digitalisation : • Aucune économie sur 1/3 du montant traité annuellement. • Impact modéré sur 1/3 du montant traité annuellement via une transparence accrue et une stimulation de la concurrence : 0,5 % par an. • Impact important sur 1/3 des dépenses : 1 % par an. L’étude de terrain confirme ces hypothèses. Les pays africains que nous avons interrogés ont surtout cité le gain lié à l’augmentation du nombre de devis reçus pour les “petites offres”. Par exemple, en Tunisie, TUNEPS a permis de faire passer les appels d’offres pour les contrats de faible valeur de 2 à 5 offres en moyenne. Au Rwanda, avant le déploiement d’UMUCYO, le nombre moyen d’offres par petit appel d’offres était d’environ 1. Aujourd’hui, le nombre moyen d’offres par petit appel d’offres est de 5,3. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 77 4.2.1. Analyse du ratio BCR pour les pays dont les dépenses en marchés publics sont inférieures à 1 milliard de dollars Investir dans un projet CUSTOM n’est pas intéressant pour ces “petits” pays. Dans le scénario « Cas d’usage », le BCR est légèrement inférieur à 1, ce qui signifie que le pays a du mal à récupérer les fonds investis. En cas de difficultés importantes rencontrées au cours du projet CUSTOM (« Cas dégradé »), l’investissement n’est pas du tout rentable. Il y a une perte de valeur importante avec un BCR inférieur à 0,6. Ceci est dû à la fois à l’augmentation significative du coût de mise en œuvre et à l’allongement des délais qui réduit la production de gains financiers sur la période. Les projets COTS ne semblent pas non plus très appropriés, car leur intérêt financier est plutôt limité avec un ratio BCR de 1,37 dans le scénario « Cas d’usage » et un risque de perte financière dans le scénario « Cas dégradé » avec un BCR proche de 1. Seuls les projets SaaS semblent apporter un avantage financier dans tous les scénarios. De ce point de vue, ils constituent les types de mise en œuvre les plus pertinents pour les pays où les marchés publics n’atteignent pas une taille critique pour justifier d’autres types de mise en œuvre. Cas Cas Cas théorique d’usage dégradé Custom 1.26 0.94 0.59 COTS 1.57 1.37 1.05 SaaS 2.20 1.95 1.58 4.2.2. Analyse du ratio BCR pour les pays dont les dépenses en matière de marchés publics se situent entre 1 milliard et 1,5 milliard de dollars Pour ces pays, les 3 types de mise en œuvre représentent un investissement intéressant dans le scénario « Cas d’usage ». Cependant, le scénario SaaS offre un retour sur investissement deux fois plus élevé que les projets CUSTOM et 42% plus élevé que les projets COTS. De plus, dans le scénario « Cas dégradé “, le SaaS continue à offrir un bon retour sur investissement et les projets COTS un retour correct, ce qui n’est plus le cas pour le projet CUSTOM. Pour ces pays, les projets CUSTOM ont donc un profil de risque plus élevé que les deux autres types de mise en œuvre. Cas Cas Cas théorique d’usage dégradé Custom 2.27 1.72 1.06 COTS 2.83 2.47 1.90 SaaS 3.96 3.51 2.84 78 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 4.2.3. Analyse du ratio BCR pour les pays ayant une dépense en marchés publics de 3 milliards de dollars De même, pour ces pays, les 3 types de mise en œuvre représentent un investissement intéressant dans le scénario « Cas d’usage ». Cependant, le scénario SaaS offre un retour sur investissement presque deux fois plus élevé que les projets CUSTOM et 38% plus élevé que les projets COTS. De plus, dans le scénario « Cas dégradé », SaaS et COTS continuent à offrir un bon retour sur investissement, ce qui est moins vrai pour le projet CUSTOM. Une fois encore, pour ces pays, les projets CUSTOM ont donc un profil de risque plus élevé que les deux autres types de mise en œuvre. Cas Cas Cas théorique d’usage dégradé Custom 4.01 3.00 1.84 COTS 4.97 4.40 3.39 SaaS 6.84 6.02 4.53 4.3. Analyse coûts-avantages (ACA) Ce chapitre synthétise les conclusions des chapitres précédents, notamment celles de la modélisation financière, de l’étude de marché, de l’étude de terrain et des entretiens menés dans les pays africains. Ce chapitre compare les avantages et les inconvénients des trois types de mise en œuvre sur la base des critères d’évaluation suivants : Temps de mise en oeuvre Facilité du projet Adéquation de la solution Avantages Interopérabilité Maintenabilité Sécurité Souveraineté TCO Coûts Facilité de gestion du budget Risque d’échec CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 79 4.3.1. Délai de mise sur le marché Custom COTS SaaS Temps de mise en oeuvre Le délai de mise en œuvre comporte deux composantes : la phase d’acquisition et à la phase de Design et de Build. 4.3.1.1. Un processus d’acquisition de 9 mois en moyenne Notre étude sur le terrain montre que la durée moyenne d’acquisition de l’e-GP est d’environ 9 mois, quel que soit le type de mise en œuvre. Pour ces trois types de projets, il est théoriquement nécessaire de définir la solution cible le plus précisément possible : ses fonctionnalités, ses interfaces avec d’autres systèmes, l’architecture technique et les exigences de sécurité. Dans le cas des projets CUSTOM, il est essentiel d’avoir aligné les différentes parties sur la priorisation des fonctionnalités. Il est également nécessaire de les décrire de manière suffisamment précise pour que les différents prestataires puissent établir un devis. Dans le cas des projets COTS et SaaS, une hiérarchisation similaire des besoins doit être faite à un niveau de granularité précis. Le cahier des charges transmis aux prestataires doit comporter une liste précise des fonctionnalités attendues (dans une annexe dédiée, le plus souvent dans Excel), des besoins d’interfaçage et les exigences sécurité. Les différents modes diffèrent ensuite plus fortement dans la manière d’évaluer les offres des fournisseurs. Dans le cas d’un projet CUSTOM, l’évaluation porte le plus souvent sur la méthodologie proposée par le fournisseur, son expérience dans des contextes similaires et l’équipe mobilisée pour réaliser le projet. Dans certains cas, le processus de sélection peut inclure la présentation d’une maquette afin de départager les fournisseurs. Cependant, cette maquette présente généralement l’architecture des menus et comporte évidemment peu de fonctionnalités. Dans le cas des projets COTS/SaaS, en plus des critères mentionnés ci-dessus, l’évaluation va beaucoup plus loin sur les fonctionnalités. En fait, il s’agit de réaliser une analyse d’écart entre les attentes du gouvernement et les différentes solutions du marché. L’un des moments clés est l’organisation de démonstrations avec les différents éditeurs de logiciels, qui permettent d’élaborer des scénarios à partir d’études de cas (préparées par les prestataires selon les directives données dans le cahier des charges par le gouvernement). L’analyse menée est donc plus précise mais aussi plus lourde à conduire. Les retours d’expérience ont mis en évidence plusieurs risques importants lors de la phase d’acquisition. (Voir le critère « risque d’échec »). 80 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 4.3.1.2. La phase de Design et de Build : Projets CUSTOM et COTS (avec un niveau élevé de développements spécifiques) L’étude de terrain a mis en évidence que les projets CUSTOM ou COTS avec une part importante de « customization » s’étalent généralement sur plusieurs années en fonction du nombre de pouvoirs adjudicateurs et de la portée fonctionnelle du projet. La durée moyenne pour ces deux types de projets e-GP est de 25 mois pour les phases de Design et de réalisation. Le calendrier de mise en œuvre le plus court observé pour un système e-GP CUSTOM/COTS relativement complet est celui du Rwanda (12 mois). Schéma 30 : Durée moyenne des projets CUSTOM / COTS (avec un niveau élevé de personnalisation) Minimum Maximum 12 mois 60 mois Moyenne 25 mois La complexité de ces types de mise en œuvre, et en particulier le nombre de chantiers à coordonner simultanément (voir le paramètre “complexité du projet” de l’analyse), entraîne souvent des retards dans le calendrier des projets. En moyenne, les pays étudiés qui ont opté pour ces types de mise en œuvre ont constaté un écart d’environ 60 % par rapport au calendrier initial (ce qui est conforme à notre modélisation). Schéma 31 : Décalage moyen par rapport au planning initial Décalage moyen par rapport au calendrier initial +130% +20% Maximum observé +60% Minimum observé CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 81 Projets SaaS et COTS avec un faible niveau de personnalisation Les projets SaaS et COTS avec une faible proportion de « customization » sont plus rapides si la phase d’acquisition a été mené de manière approfondie. En pratique. La mise en place d’un logiciel SaaS prend généralement quelques mois. Notre modélisation conduit à la conclusion que la planification dans le scénario « Cas d’usage » est de 9 mois et de 13 mois dans le « Cas dégradé ». Ces chiffres sont bien supérieurs au temps moyen estimé par les éditeurs d’e-GP ayant participé à l’étude de marché (7 mois). Il y a probablement plusieurs explications à cela : • La plupart des fournisseurs consultés ont peu d’expérience du marché africain et ont tendance à sous-estimer les facteurs qui ralentissent le processus de mise en œuvre. • Ils ne voulaient pas afficher des temps de mise en œuvre “ non-vendeurs “. 4.3.2. Facilité de mise en œuvre Custom COTS SaaS Facilité du projet Projets CUSTOM et COTS (avec un haut niveau de développements spécifiques) • Comme nous l’avons détaillé au chapitre II, les logiciels CUSTOM et COTS avec un niveau élevé de « customization » sont des projets très exigeants pour le client. Lorsqu’une organisation décide de commencer le développement d’un logiciel CUSTOM, elle part de zéro et doit couvrir toutes les dimensions associées au processus de développement informatique . La conception d’un logiciel CUSTOM exige donc des ressources importantes et une combinaison d’expertises pointues (voir le chapitre II). Ces expertises peuvent être difficiles à trouver en interne ou sur le marché. • Ces différentes expertises/tâches peuvent également être complexes à coordonner. Pendant toute la durée du projet, l’équipe de projet gouvernementale doit avoir une solide expérience en gestion de projet informatique, permettant de coordonner et de contrôler l’avancement des différentes équipes techniques et de valider leur travail : Architecte système, UI (User Interface), UX (User Experience), Ingénieurs Frontend, Ingénieurs Backend, Lead Developer, ressources pour installer et gérer les infrastructures techniques (serveurs) pendant la phase du projet... • Cette complexité est multipliée si la gouvernance du projet subit elle-même des difficultés. Lorsque les choix fonctionnels ne sont pas exposés et décidés en amont (règles de gestion, workflows, matrices d’autorisation, modèle de données) et qu’il faut “ casser “ pour reconstruire, toute l’expertise technique doit être mobilisée à nouveau. Cela peut entraîner de nombreux allers-retours entre les différentes couches techniques du projet, ce qui devient très complexe à gérer. La direction du projet doit également avoir une compréhension très fine des enjeux métiers et des besoins fonctionnels. 82 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE • Dans les projets CUSTOM, les tests de la solution peuvent également être très difficiles. Étant donné que le logiciel est le plus souvent conçu à partir de zéro, il est nécessaire de procéder à plusieurs séries de tests pour s’assurer qu’il n’y aura pas de bogue ou de problème majeur lié au code. Projets SaaS COTS (avec un faible niveau de « customization ») • Comme les fonctionnalités sont déjà développées, la complexité de ces projets est logiquement moindre. Comme détaillé au chapitre II, ces projets suivent un processus assez différent de celui des projets CUSTOM, avec plus d’efforts consacrés à l’analyse des exigences fonctionnelles, aux tests et à l’interfaçage (et évidemment moins à la conception et au code). • Il y a moins d’expertise technique à mobiliser et à coordonner sur ce type de mise en œuvre. La direction du projet est donc moins mobilisée par les questions techniques et se concentre davantage sur la manière de modéliser les attentes fonctionnelles dans les différents modules de la solution choisie. Beaucoup moins de ressources (personnel, savoir- faire et machines) sont nécessaires par rapport à un projet CUSTOM. L’équipe classique est composée d’éditeurs de logiciels et/ou de partenaires d’intégration certifiés en charge de la conception générale et détaillée de la solution cible, d’experts techniques en charge de la configuration (paramétrage des modules). • La participation du client est moins intense que sur un projet CUSTOM. Le rôle du client se concentre sur les activités suivantes : • Définir et hiérarchiser les besoins. Le client doit développer un cadre d’évaluation structuré sur les besoins des principales parties prenantes. • Assurer la gouvernance globale du projet et les comités de pilotage qui permettent d’arbitrer les décisions fonctionnelles. • Assurer la mobilisation des équipes internes pour que le produit réponde aux attentes, notamment lors des phases de test. • Gérer les interactions avec l’éditeur et/ou l’intégrateur E-GP sur le plan technique, administratif et commercial. 4.3.3. Adéquation de la solution Custom COTS SaaS Adéquation de la solution L’adéquation de la solution se mesure à l’aune de deux critères : • La capacité à répondre aux exigences des utilisateurs finaux et à refléter les “règles du métier”. • La facilité d’utilisation CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 83 4.3.3.1. Capacité à répondre aux exigences de l’utilisateur final En théorie, le principal attrait des logiciels CUSTOM est la capacité à couvrir toutes les exigences fonctionnelles. Dans les faits, le client n’obtient pas exactement ce qu’il veut, mais plus précisément ce qu’il est capable d’écrire dans des spécifications fonctionnelles détaillées au début du projet. En outre, les contraintes en matière de ressources et de techniques pénalisent souvent le rendu final. L’enquête de terrain fournit un aperçu intéressant sur ce point. Les pays qui ont déjà mis en œuvre un projet e-GP ont été invités à évaluer la réalisation des objectifs initiaux assignés à leur projet. Le schéma ci-dessous met en évidence les écarts importants entre les ambitions fonctionnelles initiales et les résultats obtenus dans les projets CUSTOM et COTS avec un niveau élevé de « customization ». Schéma 32 : Atteinte des objectifs initiaux du projet Sur une échelle de 1 à 10, comment évaluez-vous la réalisation des objectifs initiaux du projet ? % of répondants 10/10 7/10 12,5% 6/10 25% 5/10 12,5% 3/10 12,5% 2/10 25% 12,5% Les solutions SaaS d’e-GP répondent généralement aux besoins de la plupart des organisations publiques. Au fil du temps, elles intègrent les meilleures pratiques de nombreux organismes publics dans le développement du produit, afin de maximiser la satisfaction du client. Certaines règles de gestion ou processus très spécifiques seront toutefois plus difficiles à traduire dans la solution retenue. Lorsqu’un système SaaS est choisi, la plupart des exigences sont immédiatement satisfaites alors que d’autres sont en effet plus ou moins faciles à mettre en œuvre. La capacité à s’adapter aux processus du client dépend alors fortement de la capacité de configuration du logiciel choisi (c’est un point majeur d’évaluation lors de l’appel d’offres). Le client doit également faire preuve d’une certaine flexibilité et être prêt à renoncer à certaines exigences trop particulières le cas échéant. Sur les projets COTS, outre la capacité de configuration, les chefs de projet disposent d’une autre solution de remédiation : l’ajout de code personnalisé aux composants pour fournir les fonctionnalités manquantes (veuillez-vous référer au chapitre II pour plus de détails). Dans plusieurs projets COTS que nous avons étudiés (veuillez-vous référer aux études de cas), certaines fonctionnalités manquantes à la solution retenue ont été ajoutées via des développements spécifiques importants. 84 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 4.3.3.2. Facilité d’utilisation Les logiciels SaaS bénéficient du retour d’expérience de milliers d’utilisateurs, ce qui leur permet d’améliorer la facilité d’usage des fonctionnalités au fil du temps (les éditeurs utilisent aussi le terme « ergonomie »). Il existe généralement une forte corrélation entre le nombre d’utilisateurs et la facilité d’utilisation d’une solution. La plupart des développeurs de SaaS e-GP sont également engagés dans une véritable course à la facilité d’utilisation. L’une des tendances fortes de ces dernières années consiste à rendre les plates-formes commerciales aussi faciles à utiliser que les plates-formes B2C (Business to Consumer). L’expression couramment utilisée est par exemple de créer des fonctionnalités “ Amazon like “. Il est certain que les éditeurs SaaS e-GP consacrent une part importante de leur R&D à l’amélioration constante de l’ergonomie utilisateurs. L’amélioration de cette dernière est souvent une composante importante des mises à jour proposées par les éditeurs. Il est difficile pour les projets CUSTOM d’être aussi performants sur cette dimension. Par exemple, il sera difficile de mobiliser un ingénieur Interface Utilisateur (UI) ou un expert en expérience utilisateur (UX) sur les écrans tout au long du cycle de vie produit : la ressource est rare sur le marché et doit être intégrée au projet le plus tôt possible. 4.3.4. Interopérabilité (capacité à s’interfacer avec d’autres systèmes gouvernementaux) Custom COTS SaaS Interopérabilité Les solutions SaaS/COTS ont tendance à être supérieures en ce qui concerne la connexion avec des applications tierces, car elles sont dotées d’API “intégrées”, qui sont des “connecteurs” permettant à deux programmes d’échanger des informations. Les API ouvertes permettent à la plupart des solutions SaaS de s’intégrer à un large éventail de logiciels tiers. Dans les projets CUSTOM, il est généralement difficile de concevoir (par manque d’expérience) et de mettre en œuvre une solution cohérente avec tous les moteurs d’interface possibles. Les solutions CUSTOM sont généralement beaucoup moins avancées dans leurs capacités d’interfaçage. De plus, la diversité des projets d’interfaçage traités par les développeurs e-GP et les intégrateurs en mode SaaS leur confère une courbe d’apprentissage importante. Cette dernière leur permet généralement de réaliser à moindre coûts et dans des planning mieux maîtrisés les interfaces. Quel que soit le type d’implémentation retenu, il faut garder à l’esprit que la limitation provient parfois du système tiers avec lequel le système e-GP est interfacé. Il est important de vérifier dans quelle mesure les logiciels existants disposent des « portes d’entrée » nécessaires à l’échange d’information. Si l’on prend l’exemple d’un système e-GP qui doit transmettre des informations sur les commandes/factures une fois celles-ci approuvées, il convient de vérifier en amont si le système IFMIS est capable de “dialoguer” avec d’autres logiciels (généralement par le biais d’API) et comment il est en mesure de traiter et de recevoir des flux de données. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 85 Les projets d’interface avec les solutions IFMIS sont souvent confrontés à des défis importants, quel que soit le type d’implémentation. La première difficulté est d’assurer la cohérence des données entre les systèmes e-GP et IFMIS. En effet, ces interfaces sont rarement basées sur des protocoles en temps réel, qui surchargeraient l’application et dégraderaient fortement l’expérience utilisateur. Les données sont généralement échangées une fois par jour dans un batch nocturne et certaines données référentielles (fournisseurs, contrats...) peuvent donc exister à plusieurs endroits avec des divergences potentielles. Il est donc impératif de définir quel système est maître sur l’autre afin de garantir l’unicité et la cohérence des données. Ces interfaces nécessitent donc la mise en place de processus compliqués de test et de validation des données. Les outils e-GP les plus avancés du marché permettent d’appliquer des règles précises (telles que le chargement des données en plusieurs étapes selon certaines conditions, la vérification des doublons, etc.). La capacité à paramétrer des règles de chargement/vérification des données échangées est un critère d’évaluation très important lors de la sélection des solutions. En outre, les interfaces IFMIS-e-GP sont des projets informatiques complexes à mettre en œuvre. Les fonctionnalités d’envoi et de réception de données (comment le logiciel se connecte- t-il techniquement à un autre système pour y déposer des informations ?) ont été grandement améliorées au cours des 10 dernières années. Il est donc aujourd’hui plus facile d’échanger des données “courantes” par le biais d’API et de connecteurs normalisés. Toutefois, dès que la structure des données est modifiée du côté de l’e-GP ou de I’IFMIS, l’échange de données est plus complexe. Plus les applications s’éloignent du “standard”, plus l’effort est important pour adapter les tables et les “boîtes à outils” et plus il est nécessaire de réaliser des allers-retours pour développer et tester les deux demi-interfaces (celle qui “envoie” et celle qui “reçoit”). L’équipe projet doit donc veiller à ne pas trop déformer le modèle de données de la solution e-GP, c’est-à-dire à ne pas trop s’éloigner de la structuration des tables “standard” afin de faciliter la maintenance des interfaces dans le temps. Dans le cas contraire, cela peut conduire à de grandes difficultés pour maintenir les interfaces e-GP/IFMIS. 86 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 4.3.5. Maintenabilité Custom COTS SaaS Maintenabilité La maintenabilité peut être définie comme suit : • La facilité à administrer le système, tant sur le plan technique que fonctionnel. • La capacité d’améliorer le système au fil du temps 4.3.5.1. Facilité d’administration technique et fonctionnelle En mode SaaS/COTS, l’éditeur e-GP prend en charge les modifications nécessaires à l’intégration des différentes briques logicielles qui composent la solution. L’éditeur offre également la garantie contractuelle que ces briques seront parfaitement adaptées. En d’autres termes, le modèle SaaS se charge de l’intégration des briques de base et le client n’a pas à s’en soucier. Par exemple, la mise à jour des protocoles SSO (Single Sign On) pour une interface d’identification des utilisateurs se fera de manière transparente pour le client. Dans les projets CUSTOM, c’est à l’équipe technique de faire les études d’impact, le développement et les tests, ce qui est forcément plus coûteux. La gestion mutualisée du versioning des composants est également un atout majeur en SaaS/ COTS. Les développeurs SaaS/COTS disposent d’outils et d’équipes qui leur permettent de connaître les versions actuelles des différents composants standards utilisés dans un système e-GP (moteur de recherche, extracteurs excel, composants graphiques, etc.). L’expérience sur le terrain montre que les projets CUSTOM ne sont généralement pas aussi bien organisés à cet égard. Ils n’anticipent pas toujours l’effort nécessaire à la mise à jour des composants. Les budgets de maintenance sont généralement utilisés pour maintenir l’application en l’état, mais ne laissent pas toujours suffisamment de temps pour étudier les mises à jour. Il s’agit d’un problème majeur, car un mauvais contrôle des versions des composants peut entraîner des failles de sécurité et des coûts plus élevés : il est toujours plus coûteux d’effectuer une mise à jour importante dans l’urgence que de la gérer progressivement. En mode SaaS, des fonctionnalités permettant à des ressources “non techniques” de prendre en charge l’administration fonctionnelle sont mises à disposition. Le client n’a pas besoin d’accéder aux couches techniques de l’outil pour effectuer les modifications habituelles sur les profils, les seuils et les « workflows ». Dans les solutions SaaS/COTS, l’administration fonctionnelle et technique de l’outil au quotidien est prise en compte très tôt dans le cycle de Design. Une part importante de la phase Design est consacrée à anticiper la manière dont les clients pourront modifier les règles qu’ils ont spécifiées à un moment donné. L’expérience de l’éditeur de logiciel e-GP sur les différents cas de figure à anticiper est alors un atout majeur pour bien “penser” la solution. Sur les projets CUSTOM, il est plus difficile d’anticiper les besoins réels en termes d’administration fonctionnelle. Il est assez fréquent que les fonctionnalités d’administration développées sur des projets CUSTOM soient peu utilisées et que d’autres manquent fortement. Ceci est dû à la difficulté de faire converger le point de vue fonctionnel (sur la gestion quotidienne de l’outil) et le point de vue technique dès le début du projet. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 87 4.3.5.2. Capacité à améliorer le système dans le temps Les solutions SaaS/COTS intègrent en permanence les commentaires des clients afin de maximiser la satisfaction des clients et maintenir leur avantage concurrentiel. Les solutions SaaS/COTS suivent aussi généralement les techniques de développement « agile », une approche qui favorise les cycles de développement courts et les nouvelles versions à un rythme rapide. Dans le cadre de ce processus, les entreprises SaaS/COTS intègrent des tests utilisateurs approfondis afin d’aligner les spécifications du produit sur les demandes du marché. Les coûts sont compris dans leur modèle de tarification, de sorte qu’il n’y a pas de “factures surprises” pour les mises à niveau. L’étude de marché montre que les éditeurs SaaS/COTS interrogés réalisent au moins une version majeure de leur produit chaque année (et jusqu’à deux versions majeures par an). L’analyse montre que ces versions contiennent des améliorations au niveau de l’ergonomie ou des améliorations de l’administration fonctionnelle, ainsi que de nouvelles fonctionnalités. Cependant, il est important de garder à l’esprit que les demandes d’évolution transmises à l’éditeur SaaS/COTS seront qualifiées parmi des centaines d’autres. Elles ne seront probablement pas toutes intégrées dans les prochaines versions. Il arrive aussi assez souvent que la « roadmap » de l’éditeur soit plus influencée par ses propres orientations stratégiques (volonté de se diversifier avec de nouveaux types de clients, de contrer les avancées d’un concurrent...). Ces orientations ne correspondent pas toujours aux évolutions considérées comme prioritaires par le client. On considère généralement que plus le client est stratégique pour l’éditeur, plus ses demandes sont priorisées. Ainsi, il est parfois judicieux de faire appel à un éditeur de taille intermédiaire afin de ne pas être « noyé » dans la masse. En théorie, un logiciel CUSTOM permet d’ajouter ou de supprimer des fonctionnalités au fil de l’eau. Mais en pratique, une fois le logiciel mis en production, l’équipe de projet est souvent en partie dissoute et réaffectée à d’autres projets. Même lorsque ce n’est pas le cas, chaque évolution du produit est un mini projet qui coûte du temps et de l’argent. Un trop grand nombre d’évolutions sur un projet CUSTOM peut entraîner un risque de dispersion qui finit par pénaliser la valeur apportée aux utilisateurs finaux. 4.3.6. Sécurité Custom COTS SaaS Sécurité La sécurité des solutions e-GP, qui sont relativement exposées au risque d’attaque, comporte deux composantes principales : • La sécurité applicative • La sécurité des données 4.3.6.1. Sécurité applicative Ce n’est pas tant le type d’implémentation qui définit le niveau de sécurité des applications mais plutôt la qualité intrinsèque du code source. Cependant, l’enquête a clairement démontré que les éditeurs SaaS/COTS déploient plus de ressources pour garantir la sécurité des applications que les solutions CUSTOM. Garantir un niveau de sécurité maximal nécessite des ressources internes très expérimentées et peut s’avérer très coûteux. Par conséquent, l’avantage du modèle SaaS/COTS est évidemment que le coût « sécurité » est mutualisé entre tous les clients. 88 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE L’étude de marché souligne que les principaux éditeurs de logiciels SaaS mettent en œuvre de solides politiques de sécurité et disposent de processus de sécurité très stricts. La sécurité étant au cœur de leur modèle économique, les éditeurs de logiciels SaaS y consacrent des ressources très importantes. • L’étude de marché a mis en évidence que certains éditeurs effectuent des revues de code par des organismes indépendants (idéalement avant la sortie de chaque nouvelle version pour contrôler l’apparition de nouvelles vulnérabilités). • Les éditeurs de logiciels les plus avancés effectuent des tests de pénétration avec le système des 3 boîtes : boîte noire (les testeurs ne connaissent rien de l’application et tentent de s’y introduire par tous les moyens), boîte grise (un utilisateur inscrit sur l’application tente de trouver une faille pour acquérir de nouvelles autorisations), boîte blanche (le testeur a accès au code et identifie les failles de sécurité dans les différentes couches du code). • Les éditeurs de logiciels étudiés disposent parfois d’une équipe de sécurité dédiée. Parmi les principaux éditeurs de logiciels, les équipes de sécurité sont composées de 5 à 10 ingénieurs, dédiés à la sécurité de l’application. • Selon les informations remontées dans l’enquête terrain, ces meilleures pratiques n’ont pas été mises en œuvre sur les projets CUSTOM étudiés 4.3.6.2. Sécurité des données Les différentes analyses n’ont pas démontré la supériorité d’un modèle par rapport à un autre sur la sécurité des données. En ce qui concerne l’hébergement des données, il existe différentes variantes d’hébergement dans les modèles SaaS/COTS. Il est recommandé de s’orienter vers des solutions “ single-tenant “ pour les solutions e-GP, de choisir un éditeur évalué par des tiers indépendants et de retenir une solution qui crypte les données stockées dans le cloud. Il convient également de vérifier la capacité des éditeurs e-GP à se remettre rapidement d’un incident de perte de données à grande échelle. 4.3.7. Souveraineté Custom COTS SaaS Souveraineté 4.3.7.1. Souveraineté des données Les solutions CUSTOM et COTS sont généralement associés à l’hébergement sur site (« on premise »). En Afrique, il existe plusieurs cas d’hébergement « sur site » (serveurs hébergés dans les locaux de l’autorité compétente). Mais une tendance semble se développer en faveur de centres de données mutualisant l’hébergement des solutions informatiques utilisées par les gouvernements. Quelques exemples de ces “clouds gouvernementaux” sont détaillés dans les études de cas. Ces deux types d’hébergement offrent des garanties substantielles en matière de souveraineté des données. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 89 Par définition, un système SaaS e-GP est dans le cloud. Mais cela ne signifie pas qu’il n’y a aucune garantie de souveraineté : • Il est techniquement possible que la solution soit hébergée dans un centre de données dans le pays du client. • La plupart des éditeurs d’e-GP proposent une architecture “single-tenant” (multi- instance) qui garantit le partitionnement total des données entre les clients. • Il est possible d’exiger un cryptage des données au niveau du serveur qui rend les données inaccessibles à toute personne ayant un accès physique aux centres de données. Il convient de mentionner le cas particulier des éditeurs de logiciels dont la maison mère se trouve aux Etats-Unis. En vertu du principe d’extraterritorialité du Clarifying Lawful Overseas Use of Data Act ou CLOUD Act (H.R. 4943) (i), un éditeur américain de solutions e-GP et/ou un éditeur hébergeant des données de clients via un fournisseur de centre de données soumis au droit américain est tenu de transmettre toutes les données requises par les autorités américaines. Par conséquent, la nationalité du fournisseur du centre de données peut également être la clé de la souveraineté des données, indépendamment de la localisation du serveur de données. (i) Le Clarifying Lawful Overseas Use of Data Act ou CLOUD Act (H.R. 4943) est une loi fédérale américaine promulguée en 2018 par l’adoption du Consolidated Appropriations Act, 2018, PL 115-141, Division V. Le CLOUD Act modifie principalement le Stored Communications Act (SCA) de 1986 pour permettre aux forces de l’ordre fédérales d’obliger les entreprises technologiques basées aux États-Unis par le biais d’un mandat ou d’une assignation à fournir les données demandées stockées sur des serveurs, que ces données soient stockées aux États-Unis ou sur un sol étranger. 4.3.7.2. Capacité à gérer et à faire évoluer l’outil de manière autonome Les trois modes permettent au client de maîtriser l’évolution de l’outil. Dans les projets CUSTOM, cet objectif sera atteint en pérennisant les équipes qui ont géré la phase de projet et la gestion du changement. Il est important de prévoir le financement de ces équipes au- delà de la phase projet, comme l’ont souligné plusieurs pays interrogés. Selon les projets observés, ces équipes comptent entre 15 et 20 ETP : propriétaires de produits, ingénieurs de développement et de réseau, administrateurs techniques et fonctionnels, ainsi que des équipes de formation et de helpdesk. Si le gouvernement a externalisé les développements en mode CUSTOM, il devra effectuer un transfert de savoir-faire vers les équipes internes s’il souhaite réinternaliser la maintenance de l’application en vie courante. En général, les projets CUSTOM créent une très forte dépendance à quelques ressources clés, notamment les développeurs qui ont écrit les lignes de code. Si les développeurs d’origine sont partis sans avoir suffisamment documenté l’application, il est presque inévitable que quelque chose se passe mal lorsque leur code doit être modifié. Dans les projets SaaS/COTS, on observe le même besoin de planifier et de financer les équipes gouvernementales qui prendront en charge l’administration technico-fonctionnelle de la solution (paramétrages simples ou moyennement complexes, création d’utilisateurs, etc. Ceci implique un transfert de savoir-faire de l’éditeur de logiciels vers les équipes gouvernementales : la formation des administrateurs et leur accompagnement pendant la phase de prise en main doivent être précisément décrits dans le cahier des charges et le contrat de l’éditeur de logiciels/intégrateur. Dans les projets SaaS/COTS, le client est réputé autonome sur les paramétrages simples et l’administration de l’outil après avoir été dûment formé. Lorsque les demandes de changement sont plus complexes, il est généralement fortement recommandé de recourir aux services de l’intégrateur qui a géré le projet (ou d’un autre) ou de confier ces tâches directement à l’éditeur de logiciels. Les projets SaaS/COTS introduisent donc une certaine dépendance vis-à-vis de l’éditeur de logiciel et/ou de l’intégrateur. Le contrat doit prévoir précisément la répartition des rôles et des 90 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE responsabilités pour traiter les différents niveaux d’anomalies ou les demandes de changement. Le contrat doit énumérer tous les engagements que les parties prenantes devront respecter en termes Service Level Agreement (SLA) sur les performances de l’application et les délais de correction. En outre, l’influence qu’exerce le client sur la feuille de route de l’éditeur d’e-GP peut être limitée sur les projets SaaS/COTS. Lors de la phase d’acquisition, il est donc important de s’assurer que l’éditeur e-GP couvre bien les besoins fonctionnels qui ne sont pas implémentés dans la première vague de projet (ou qu’il peut s’interfacer facilement avec une autre solution pour répondre au besoin). Il est également possible de demander aux développeurs e-GP de s’engager à fournir une fonctionnalité qui n’est pas actuellement disponible. 4.3.8. Coûts Custom COTS SaaS Coût total de possession Coûts Facilité de gestion du budget 4.3.8.1. Coût total de possession Le modèle de coût a montré que : • Les projets de mise en œuvre de solutions CUSTOM ou COTS avec une part élevée de développements spécifiques coûtent deux fois plus cher que les projets de mise en œuvre de solutions SaaS. En outre, le coût total de possession sur 5 ans pour les projets CUSTOM est 60% plus élevé que pour les projets SaaS ou COTS avec une faible part de développement spécifique. • On constate également une plus forte tendance à la dérive budgétaire des projets CUSTOM/ COTS avec un niveau élevé de développements spécifiques. La différence de budget “ Design & Build “ entre le « Cas théorique » et le « Cas d’usage » reflète les défis classiques rencontrés dans les projets informatiques (approbation, nécessité de refaire, respect des délais). Dans le cas des projets CUSTOM. La différence du budget “Design & Build” entre ces scénarios est de 22%. Dans le scénario où les difficultés du projet s’intensifient (« Cas dégradé »), la dérive budgétaire s’accentue avec un budget supérieur de près de 60% au budget “théorique”. L’approche BCR a montré que : • Pour les petits pays dont les dépenses en matière de marchés publics sont inférieures à 1 milliard de dollars, seuls les projets SaaS semblent apporter un avantage financier dans tous les scénarios. De ce point de vue, ils sont les types de mise en œuvre les plus pertinents pour les pays où les marchés publics n’atteignent pas une taille critique pour justifier d’autres types de mise en œuvre. • Pour les pays dont les dépenses en matière de marchés publics sont supérieures à 1,5 milliard de dollars, les trois types de mise en œuvre représentent un investissement intéressant dans le scénario « Cas d’usage ». Cependant, le scénario SaaS offre un retour sur investissement deux fois plus élevé que les projets CUSTOM et 42% plus élevé que les projets COTS. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 91 4.3.8.2. Facilité de gestion du budget La définition et la gestion du budget sont plus faciles sur les projets SaaS/COTS avec peu de développements spécifiques. • La modélisation financière et les études de marché ont montré que les modèles SaaS/COTS sont plus prévisibles. Le gouvernement peut plus facilement avoir une vision définitive des coûts liés à un périmètre fonctionnel donné. Les chapitres précédents ont également montré qu’il est plus facile de gérer les “ phases d’attente “ des projets SaaS/COTS (longs délais de validation ou attente d’un changement réglementaire) et que les effets “ stop and go “ sont moins coûteux. • Les modèles de tarification adoptés par les éditeurs de SaaS/COTS e-GP sont également intéressants pour leur flexibilité. Ces modèles permettent d’ajuster le montant des licences en fonction du nombre d’utilisateurs enregistrés sur l’application. En d’autres termes, le montant des licences s’adaptera au déploiement progressif du logiciel. Dans le modèle CUSTOM/COTS, avec une part importante de développements spécifiques, tous les coûts du projet sont imputés au projet indépendamment de l’utilisation réelle de la solution. 4.3.9. Risque d’échec Custom COTS SaaS Risque d’échec Forte Modéré Faible Les chapitres précédents ont montré que le risque de dérapage du budget et du calendrier est beaucoup plus important pour les projets CUSTOM et COTS ayant une forte proportion de développements spécifiques. L’étude de terrain a clairement montré que les projets CUSTOM/COTS avec une forte proportion de projets spécifiques présentent un écart important entre l’ambition initiale et la réalisation effective. D’autres risques ont été identifiés dans les chapitres précédents : • Les risques liés au processus d’achat. Les chapitres précédents ont montré que l’évaluation des offres sur les projets CUSTOM se fait sur des critères moins tangibles en l’absence d’une solution à “disséquer”. Sur les projets CUSTOM, il est parfois difficile d’évaluer la capacité d’une équipe de développeurs interne ou externe à produire l’application souhaitée. Sur les projets SaaS/COTS, le risque est de réaliser une étude insuffisamment détaillée des capacités des solutions du marché (en termes de fonctionnalités, d’intégration, de capacités d’administration, etc.) et de choisir une solution éloignée des attentes prioritaires et incompatible avec les contraintes de l’administration. • Le risque d’obsolescence ne doit pas non plus être sous-estimé. La difficulté à suivre les évolutions technologiques ne doit pas être sous-estimée car Il est de plus en plus difficile de faire les bons choix et de suivre l’évolution des frameworks, des langages, des composants... En ce sens, le modèle SaaS/COTS est plus confortable car la mise à niveau technologique de l’éditeur de logiciels est une condition de survie à long terme et est gérée de manière mutualisée pour tous les clients. 92 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE • En ce qui concerne la sécurité, il n’y a aucune raison réelle de conclure qu’un type de mise en œuvre garantit une meilleure sécurité des applications ou des données. • Le risque de dépendance et de “situation de blocage” avec le fournisseur. • S’agissant de domaines où les compétences sont rares et difficiles à retenir, il existe toujours une dépendance à certains profils clés, notamment dans les projets CUSTOM. Dans les projets SaaS/COTS, il existe un risque réel de dépendance vis-à-vis de l’éditeur de logiciels et/ou de l’intégrateur qui peuvent être les seuls à pouvoir réaliser des évolutions plus complexes. • Le scénario le plus défavorable est d’être enfermé avec un fournisseur alors que la solution reste instable, incomplète ou impossible à faire évoluer dans les contraintes de temps et de coût. Il existe quelques bonnes pratiques à prendre en compte dans ces trois types de mise en œuvre pour réduire la dépendance vis-à-vis du ou des fournisseurs : • Le premier facteur qui conduit à des situations de verrouillage est l’impossibilité de transférer les données de l’e-GP vers un nouveau système. En général, les contrats comportent un engagement du fournisseur à restituer les données “sous une forme utilisable”. Toutefois, la formulation est souvent trop vague et le vendeur se contente de remettre un fichier de données “plat”. Une bonne pratique pour les systèmes e-GP est donc d’imposer un engagement à fournir à la base de données des liens entre les tables, sans lesquels elle restera inutilisable. Dans le modèle SaaS, cet engagement peut être un peu complexe à obtenir dans la mesure où l’éditeur considère que les liens entre les tables constituent son “modèle de données” et donc sa propriété intellectuelle. Une autre bonne pratique a récemment vu le jour. Elle consiste à exporter les données en temps réel vers un “ lac de données “ à la fois à des fins décisionnelles et pour préparer un éventuel plan de migration. • Le deuxième facteur qui conduit à l’enfermement est le manque de compétences techniques au sein des équipes du gouvernement (client). Quel que soit le type de mise en œuvre, le client doit comprendre au moins les fondamentaux techniques de la solution mise en œuvre. Par exemple, il est crucial que le gouvernement sache effectuer des paramétrages simples dans le cas d’un projet SaaS ou COTS, ou qu’il puisse juger de la qualité du code développé par l’éditeur de logiciels dans le cas d’un projet CUSTOM. Ces connaissances techniques permettront d’alerter les sponsors du projet au bon moment et de prendre des décisions : limites techniques de la solution choisie justifiant des contournements, alertes sur des choix techniques trop complexes à maintenir ou présentant des risques importants de régression dans le temps, etc.... Ces connaissances techniques permettront également de challenger les propositions des éditeurs de logiciels (en termes de délais et de budgets) et de mieux les gérer tout au long des phases. Dans les trois types de mise en œuvre, le transfert de savoir-faire doit être organisé dès les premières étapes. Dans les projets COTS/SaaS, il existe généralement une approche structurée de certification qui permet aux équipes internes de se former et de mettre à jour leurs connaissances relativement facilement. Dans les projets CUSTOM ou COTS avec un niveau élevé de « customization », la meilleure pratique est d’impliquer les équipes internes dans le développement le plus tôt possible. CHAPITRE IV - ANALYSE COÛTS-AVANTAGES I 93 • Il est également nécessaire de formaliser des engagements très clairs sur la documentation technique et fonctionnelle du projet et surtout sur sa mise à jour tout au long du cycle de vie de la solution. La mise à jour des spécifications de configuration (SaaS), des spécifications techniques et fonctionnelles des différents modules (CUSTOM/COTS), et la description des interfaces doivent être incluses dans le chiffrage des prestataires. Cette exigence a nécessairement un coût, mais elle permet de sécuriser le projet et de faciliter le transfert vers un nouveau prestataire ou vers des équipes internes. • Enfin, afin d’éviter les blocages liés aux négociations tarifaires sur l’évolution de la solution e-GP, il peut être intéressant de fixer en amont le prix d’unités d’œuvre types (évolutions simples, moyennement complexes, complexes) et d’assurer la qualification “ pertinente “ des évolutions dans le temps. Plus l’équipe gouvernementale dispose de connaissances techniques sur la solution, plus elle a de chances de qualifier correctement les évolutions. Il est également conseillé d’engager contractuellement l’éditeur du logiciel à inclure dans son produit telle ou telle fonctionnalité manquante (fonctionnalités non éliminatoires mais “ nice to have “ au moment de la sélection). 4.4. Synthèse de l’analyse Custom COTS SaaS Temps de mise en oeuvre Facilité du projet Adéquation de la solution Avantages Interopérabilité Maintenabilité Sécurité Souveraineté Coût total de possession Coûts Facilité de gestion du budget Risque d’échec Forte Modéré Faible Source : auteurs Chapitre V Le retour d’expérience TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 95 Chapitre V Le retour d’expérience 5.1. Introduction des études de cas L’analyse des retours d’expérience sur les projets e-GP réalisés ou en cours permet de réaliser une photographie des types d’implémentation retenus, des plannings projet, des budgets réellement dépensés et des modes d’hébergement retenus. L’étude de ces projets permet aussi de mettre en évidence quelques bonnes pratiques et points de vigilance. Méthodologie utilisée pour analyser les projets e-GP mis en œuvre en Afrique Nous avons envoyé une “matrice de collecte de données” à tous les gouvernements africains pour en savoir plus sur leurs projets e-GP. La matrice était divisée en plusieurs sections, que les responsables de projets e-GP étaient invités à remplir : • Identité : informations générales sur le projet (type de solution, année de démarrage du projet, éditeur de logiciels sélectionné, intégrateur, entité responsable, etc.) • Couverture fonctionnelle • Complexité de l’intégration : informations sur les interfaces développées • Chiffres clés du système e-GP : nombre d’utilisateurs, actifs ou inactifs, nombre d’appels d’offres, de contrats, de bons de commande, dépenses engagées via le système e-GP, gains réalisés … • Calendrier de mise en œuvre : description des différentes phases du projet • Coûts du projet : ventilés par phase (Design, Build et Run), par type (coûts des fournisseurs et coûts internes, coûts des licences). • Hébergement des données • Pertinence du système e-GP : évaluation chiffrée de la mise en œuvre du système e-GP, de l’acceptation par les utilisateurs, de la flexibilité du système, de la gestion des changements, du respect du calendrier/budget En complément, des entretiens avec les responsables projets e-GP ont été organisés pour les pays suivants : • Côte d’Ivoire • Maurice • Rwanda • Tunisie • Ouganda 96 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 5.2. Étude de cas n° 1 : Rwanda APERÇU DU PROJET E-GP RWANDAIS Schéma 33 : Étude de cas e-GP – Rwanda AUTORITÉ PUBLIQUE E-GP TYPE DE SOLUTION FOURNISSEUR COTS (Open source) KONEPS Bureau des marchés publics du Rwanda CONTEXTE En 2013, le gouvernement rwandais a signé un partenariat avec le gouvernement coréen pour développer une version personnalisée de l’e-GP coréen KONEPS. Korea Telecom et l’APPR ont créé une coentreprise appelée African Olleh Services, chargée de développer la nouvelle solution. Le RPPA est ensuite devenu propriétaire de l’e-GP et est aujourd’hui entièrement responsable de la maintenance et du support. COUVERTURE FONCTIONNELLE Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité PLANNING Partenariat entre le Fin de la conception et de la construction Déploiement Rwanda et la Corée Début de la phase pilote en cours 2013 2014 2015 2016 2017 2018 2019 2020 2021 Création de l’OEA Fin de la phase pilote Début du projet UMUCYO devient obligatoire FAITS MARQUANTS COÛT DU PROJET $12,4M Hébergement des données : Coût total depuis - Les données sont hébergées sur place, au Rwanda National Datacenter le début du projet (RNA), qui héberge les données de la plupart des systèmes gouvernementaux. Autres: Coût total des phases - Utilisation obligatoire de l’e-GP pour toutes les entités publiques (100 de Design & Build $7,8M % des dépenses de passation de marchés) Coûts de - Augmentation du nombre moyen de fournisseurs soumissionnaires fonctionnement annuels $800K par appel d’offres - 6 interfaces développées avec d’autres systèmes Dépassement des coûts None CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 97 ORGANISATION DU PROJET : En 2013, le gouvernement du Rwanda a demandé à la Banque mondiale de réaliser une étude de faisabilité sur la mise en œuvre d’une solution e-GP. Pour donner suite aux recommandations de la Banque mondiale, le gouvernement rwandais a décidé de s’associer à la Corée du Sud pour déployer une version personnalisée de l’e-GP coréen : KONEPS. Cette solution a déjà démontré sa capacité à assurer la sécurité et la transparence des marchés publics.14 Pour y parvenir, une coentreprise entre l’entreprise publique Korea Telecom (KT) et le gouvernement rwandais, nommée Africa Olleh Services (AOS) a été créée. Le gouvernement rwandais a confié le développement d’UMUCYO à cette société à la fin de 2014. La phase de Design et de développement a été prise en charge par AOS, KT fournissant près de 50 développeurs pour réaliser le Design et la Build (50% sur site). Le Rwanda Public Procurement Authority (RPPA), en charge de la gouvernance du projet, a dirigé la phase de Design. À la fin du partenariat, après avoir achevé un processus de transfert de connaissances de KT vers le RPPA, le gouvernement rwandais est devenu propriétaire du code. Aujourd’hui, la maintenance de l’application est assurée par le RPPA seul. Enfin, l’hébergement de la solution est assuré par le Rwanda National Datacenter (RND), qui est chargé d’héberger la plupart des systèmes du gouvernement rwandais. PLANIFICATION DU PROJET : Schéma 34 : Planification du projet UMUCYO Partenariat entre le Fin de la conception et de la construction Déploiement Rwanda et la Corée Début de la phase pilote en cours 2013 2014 2015 2016 2017 2018 2019 2020 2021 Création de l’OEA Fin de la phase pilote Début du projet UMUCYO devient obligatoire 2014 : Il a fallu un an pour initier le projet à partir du moment où le partenariat a été signé. 2015 - 2016 : Les phases de Design et de Build ont duré 18 mois, de 2015 à 2016. 2016 - 2018 : La phase pilote a été lancée en 2016, a duré 1,5 an, soit environ 1,5M€. 2018 : début du déploiement général, lorsque l’utilisation d’UMUCYO est devenue obligatoire pour tous les organes directeurs. Aujourd’hui, UMUCYO est toujours en cours de déploiement et d’amélioration. 14. https://www.worldbank.org/en/news/feature/2018/09/05/how-rwanda-became-the-first-african-country-with-an-electronic-procure- ment-system. 98 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE COUVERTURE FONCTIONNELLE La version actuelle d’UMUCYO est la même que celle qui a été déployée en 2018. Elle couvre la quasi-totalité de la phase de pré-attribution (à l’exception des enchères inversées). En ce qui concerne la phase post-attribution, la solution ne couvre que les fonctionnalités de gestion du catalogue. Elle dispose d’un module e-contrat qui permet uniquement de visualiser les contrats, et non de les modifier. La couverture fonctionnelle a évolué depuis le déploiement de la solution. Schéma 35 : Couverture fonctionnelle d’UMUCYO Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité Bien qu’il n’y ait pas eu de mise à niveau majeure de la version, de nombreuses fonctionnalités ont été ajoutées. Voici quelques exemples de “petites améliorations” mises en œuvre depuis 2018 : • Renforcer la limite de taille des offres • Renforcer les capacités de reporting de l’UMUCYO • Automatisation de l’ouverture des plis financiers pour les appels d’offres de consultance • Renforcer le lien avec l’IFMIS (logiciel de gestion financière) Plusieurs interfaces ont été développées depuis le début du projet. Aujourd’hui, il y a 6 interfaces actives avec d’autres systèmes gouvernementaux, y compris une interface avec le système ERP du gouvernement. L’interface avec le système IFMIS est très importante, car l’objectif du RPPA était de permettre aux acheteurs de planifier leurs procédures en tenant compte des variables budgétaires. LES INDICATEURS CLÉS : Les mesures suivantes ont été rapportées dans notre entretien d’étude de cas (2021) : Taux de couverture des marchés publics par UMUCYO 100% Nombre d’organes directeurs enregistrés dans la solution 210 Nombre total d’utilisateurs 2,000 CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 99 Les mesures suivantes ont été communiquées à partir de 2018, dans le rapport annuel 2018-2019 de l’APPR : Nombre d’appels d’offres publiés 4 895 Ouvertes 4 072 Nombre de contrats signés 4 705 Nombre de soumissionnaires ayant soumissionné au moins une fois 2 490 Nombre de soumissionnaires ayant été attributaires au moins une fois 1 601 Nombre total des offres soumises 21 586 Nombre total de fournisseurs enregistrés 6 456 Nombre moyen d’offres fournisseurs par consultation 5,3 Avant la mise en œuvre d’UMUCYO, le nombre moyen d’offres par consultation a été multiplié par 5. COÛTS DU PROJET Le budget total investi dans le projet e-GP du Rwanda est d’environ 12M$. Aucun dépassement de coût n’a été identifié. Le budget dépensé dans la phase de Design et de Build est d’environ 7,8M$. Il a été dépensé entre 2014 et 2018. Depuis le déploiement général en 2018, le budget de maintenance de l’application est estimé à environ 800K$ par an. Ce budget prend en compte les corrections de bugs, l’assistance aux utilisateurs, les coûts d’hébergement, le développement de nouvelles fonctionnalités et les coûts de matériel. L’équipe interne de l’APPR dédiée à la gestion de la solution est estimée à environ 15 personnes à temps plein. L’équipe est composée de plusieurs profils : Chef de projet, équipe de développeurs, spécialistes des marchés publics, spécialiste juridique, équipe d’exploitation (spécialistes du réseau et du matériel), informaticiens spécialisés dans les bases de données, équipe support utilisateur RETOUR D’EXPÉRIENCE : Selon les représentants rwandais, l’organisation du projet avec le gouvernement coréen et KT a permis au Rwanda d’estimer parfaitement le coût du projet et de bénéficier de l’expérience d’une solution e-GP existante. La création d’une coentreprise a probablement été l’un des facteurs clés pour éviter les dépassements de budget et mettre en œuvre une solution efficace. Cela a également beaucoup aidé à développer des caractéristiques techniques telles que les interfaces. Dans ce cas, les méthodes suivantes se sont avérées efficaces pour favoriser l’adoption de l’e-GP par toutes les parties prenantes : • Rendre l’utilisation d’UMUCYO obligatoire par la loi pour tous les organes directeurs • Cette décision oblige tous les acheteurs à s’adapter et à apprendre comment acheter par le biais du logiciel. • Cette décision oblige tous les fournisseurs désireux de participer à des appels d’offres publics à utiliser le logiciel. 100 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE • Investir dans la communication et la formation de tous les utilisateurs finaux • Démonstrations/ateliers/sessions de formation • Contenu promotionnel Youtube / guides d’utilisation • Sessions de formation dans les cafés internet Schéma 36 : Guide YouTube du fournisseur UMUCYO En ce qui concerne la gouvernance du projet, il est essentiel de constituer l’équipe projet le plus tôt possible. Le Rwanda a eu des difficultés pendant le processus de transfert de connaissances, car son équipe de projet n’était pas entièrement constituée. CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 101 5.3. Étude de cas n°2 : Tunisie OVERVIEW OF THE TUNISIAN E-GP PROJECT Schéma 37 : Etude de cas e-GP - Tunisie AUTORITÉ PUBLIQUE E-GP TYPE DE SOLUTION FOURNISSEUR COTS (Open source) KONEPS Haute instance de la commande publique (HAICOP) CONTEXTE En 2011, le gouvernement tunisien a établi un partenariat avec la Corée pour développer une version personnalisée de KONEPS, l’e-GP coréen. Aujourd’hui, TUNEPS fonctionne parfaitement et est en cours de déploiement sur l’ensemble du pays. L’HAICOP est l’unique propriétaire du code, maintient la solution et l’améliore avec l’aide de fournisseurs informatiques privés. COUVERTURE FONCTIONNELLE Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité PLANNING Partenariat avec la Corée & sélection de fournisseurs Début de la phase pilote Déploiement toujours informatiques privés 1ère publication de l’appel d’offres en cours 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 mois 60 mois 28 mois Début de la phase de conception Fin de la phase pilote et de construction TUNEPS devient obligatoire FAITS MARQUANTS COÛT DU PROJET $5,7M Hébergement des données : Coût total depuis Les données sont hébergées sur place, au CNI (Centre national de calcul), le début du projet qui héberge les données de la plupart des systèmes gouvernementaux. Autres: Coût total des phases de Design & Build N/A - 40 % de code spécifique ajouté au logiciel coréen original - Utilisation obligatoire de TUNEPS pour toutes les Coûts de instances dirigeantes fonctionnement annuels N/A - 4 interfaces développées avec d’autres systèmes Dépassement des coûts None 102 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE ORGANISATION DU PROJET En 2011, le gouvernement tunisien et le gouvernement coréen ont signé un partenariat pour développer une version personnalisée de KONEPS pour la Tunisie. Etant donné la différence entre les lois sur les marchés publics en Corée et en Tunisie, le besoin de personnalisation était important. Dans un premier temps, la HAICOP envisageait de développer un code spécifique “ en interne “ (avec des ressources informatiques internes). Les experts coréens n’avaient qu’à fournir la version standard de KONEPS et à former les ressources de la HAICOP à sa maintenance et à son amélioration. Cependant, en raison du manque de ressources techniques à l’époque, HAICOP a dû faire appel à des opérateurs externes et privés pour les soutenir dans le développement de fonctionnalités spécifiques. Ce développement spécifique a été financé par des collectes de fonds. Aujourd’hui, la HAICOP est l’unique propriétaire du code et assure la maintenance de l’e-GP avec des ressources internes (assistance aux utilisateurs et résolution des problèmes). Elle continue également à améliorer la solution avec l’aide d’opérateurs privés. La solution est hébergée sur site, au CNI (Centre National Informatique) de Tunisie, qui héberge la plupart des systèmes gouvernementaux. PLANIFICATION DU PROJET Schéma 38 : Planification du projet TUNEPS Partenariat avec la Corée & sélection de fournisseurs Début de la phase pilote Déploiement toujours informatiques privés 1ère publication de l’appel d’offres en cours 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 mois 60 mois 28 mois Début de la phase de conception Fin de la phase pilote et de construction TUNEPS devient obligatoire Juillet 2011 : Signature de la convention de financement. Création du comité technique et du comité de pilotage Juillet 2011-Décembre 2011 : Sélection d’opérateurs privés pour aider aux phases de Design et Build. 2012 : Phase de Design et de Build (12 mois) 2013 : Inauguration officielle de TUNEPS, le projet est prêt à être déployé. Lancement du processus de sélection par la KOICA pour désigner le bureau en charge du développement du système d’e- procurement en Tunisie. Juin 2014 : publication du premier appel d’offres Juin 2014-2018 : déploiement progressif sur des entités pilotes (les plus grandes entités en termes de dépenses publiques). En 2018 : suite aux résultats positifs de la phase “ pilote “, le gouvernement tunisien a promulgué un décret rendant obligatoire la dématérialisation des marchés publics via TUNEPS15. Le décret prévoyait une imposition progressive : entreprises publiques, puis ministères, puis établissements publics non administratifs et enfin une généralisation aux collectivités16. 15. https://chroniques.tn/2019/05/tuneps-le-nouveau-systeme-tunisien-dachats-publics-en-ligne-obligatoire-a-partir-de-01-septembre-2019/. 16. https://www.webmanagercenter.com/2014/06/18/151461/tunisie-marches-publics-tuneps-tn-une-avancee-dans-la-bonne-gouvernance/. CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 103 COUVERTURE FONCTIONNELLE Schéma 39 : Couverture fonctionnelle de TUNEPS Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité La couverture fonctionnelle actuelle est complète, mais elle a nécessité un important travail de développement spécifique (2012). On estime que les fonctionnalités personnalisées représentent 40% du total des fonctionnalités de l’e-GP actuel. Voici des exemples de fonctionnalités personnalisées développées pendant la phase de Design et de Build : • Authentification et profils d’utilisateurs • Contrats et marchés de faible valeur • Notifications • Téléchargement d’Excel pour les offres des fournisseurs La couverture fonctionnelle de TUNEPS est continuellement améliorée, HAICOP prévoit d’ajouter les fonctionnalités suivantes : • Le paiement électronique (approbation de la facture, interface avec les ERP du gouvernement), • Gestion des contrats et suivi des dépenses contractuelles • Gestion des litiges En ce qui concerne la gestion des contrats, l’étude de faisabilité a recommandé le développement d’un système « CUSTOM » interconnecté avec TUNEPS. Un appel d’offres visant à sélectionner un opérateur privé pour le développer est en cours. Quant aux interfaces, 3 sont développées et entièrement fonctionnelles : • 1 Interface avec le SI financier gouvernemental permettant de vérifier l’attestation relative au statut fiscal. • 1 interface avec le système de sécurité sociale permettant de vérifier l’affiliation du soumissionnaire à un système de sécurité sociale • 1 interface avec le SI de la banque centrale permettant la transmission du taux de change interbancaire (pour la conversion des offres en devises étrangères) 104 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE En 2020, la Corée et la Tunisie se sont à nouveau associées pour lancer le projet TUNEPS 217, afin d’améliorer la solution actuelle (Mise à jour des fonctionnalités, centre de formation, upgrade des équipements matériels, …) LES INDICATEURS CLÉS : Les métriques suivantes sont issues de notre entretien avec les représentants tunisiens : Nombre d’acheteurs publics enregistrés sur la solution (utilisateurs) 1 350 Nombre annuel d’appels d’offres traités par la plateforme 6 000 Nombre de fournisseurs enregistrés dans TUNEPS 12 00018 L’un des principaux avantages est l’augmentation du nombre moyen d’offres pour les petits achats. Il est passé de 3 en moyenne avant la mise en œuvre de TUNEPS à 5 en moyenne aujourd’hui. COÛTS DU PROJET En 2011, le coût total estimé du projet était d’environ 5,7M$. Les coûts de Design et de Build étaient d’environ 4,8 M$. Les coûts annuels de fonctionnement depuis 2014 sont d’environ 155 000$/an (935 000$ sur 6 ans), dont 72 000$ de frais d’hébergement. À ce stade, aucun dépassement de coût n’a été identifié. Des fonds sont encore dépensés pour améliorer le logiciel (le module de gestion des contrats électroniques sera bientôt développé). En 2021, le personnel de l’unité « e-procurement » de la HAICOP est estimé à environ 19 équivalents temps plein (ETP), réparti en 3 groupes : • Un groupe “gestion de projet” : environ 7 ETP • Un groupe “techniciens/ingénieurs” : environ 6 ETP (2 ingénieurs de développement, 2 ingénieurs système, 1 ingénieur réseau, une personne dédiée aux tests). • Un groupe Helpdesk : environ 5 ETP • 1 assistant à temps plein RETOUR D’EXPÉRIENCE : En termes d’organisation du projet : • Lors de la conception des équipes de projet, s’assurer de disposer de suffisamment de ressources techniques pour être autonome dans le développement de fonctionnalités spécifiques. Comme HAICOP ne disposait pas des ressources internes requises et a décidé de ne pas recruter, elle a dû faire appel à des opérateurs privés pour réaliser les développements spécifiques. 17. https://africanmanager.com/25-musd-de-la-coree-du-sud-pour-le-tuneps-2/. 18. https://www.oecd.org/mena/governance/improving-e-procurement-environment-tunisia-fr.pdf CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 105 • Le budget initial ne tenait pas compte des éléments de communication et de sensibilisation, ce qui a rendu plus difficile l’adoption de la solution par tous lors de la phase de mise en œuvre. Cette composante du projet a été sous-estimée. Dès le départ, il faut prévoir un plan d’action pour le déploiement/communication et le financement associé. Lorsque la solution est prête à être déployée : • Rendre l’utilisation de l’e-GP obligatoire pour toutes les entités concernées est un excellent moyen de favoriser l’adoption du logiciel • Il est nécessaire que le gouvernement fournisse des fonds pour garantir le maintien en condition opérationnelle et l’amélioration du système e-GP. Dans le cas tunisien, l’unité d’e- procurement de HAICOP devrait avoir un budget alloué afin d’anticiper la fin des budgets fournis par les collecteurs de fonds. • Il serait également intéressant de donner à la HAICOP le statut d’une autorité réglementaire sur le système e-GP. 106 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 5.4. Étude de cas n°3 : Ouganda APERÇU DU PROJET E-GP OUGANDAIS Schéma 40 : Etude de cas e-GP - Ouganda AUTORITÉ PUBLIQUE E-GP TYPE DE SOLUTION FOURNISSEUR COTS EUROPEAN DYNAMICS Autorité chargée des marchés publics et de la cession des biens publics CONTEXTE Après avoir réalisé une étude avec EY, l’autorité chargée des marchés publics et de la cession des biens publics a confié le développement de l’e-GP ougandais à European Dynamics. L’objectif initial était de construire une suite S2P de bout en bout, obligatoire pour tous les entités publiques. Le portail a été développé en 4 ans et est actuellement en phase pilote. En même temps, le gouvernement ougandais a lancé un nouveau projet pour développer en interne un autre e-GP, qui devrait être prêt en 2023. COUVERTURE FONCTIONNELLE Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité PLANNING Étude préliminaire avec Attribution à ED EY pour concevoir le Début de la conception Phase pilote modèle de base et de la construction encore en cours 2014 2015 2016 2017 2018 2019 2020 2021 8 mois 28 mois 24 mois 18 mois Début de la phase Fin de la phase D&B de passation de marchés Début de la phase pilote FAITS MARQUANTS COÛT DU PROJET $4,15M Hébergement des données : Coût total depuis Les données sont hébergées par la National Information Technology le début du projet Authority-Uganda (NITA-U), un organisme statutaire autonome. Autres: Coût total des phases de Design & Build $1,55M - 75 % de code spécifique ajouté au logiciel d’origine - Décalage par rapport au calendrier initial : 50 Coûts de - Pas d’interface en raison des coûts de développement élevés fonctionnement annuels $876K - Lancement d’un nouveau projet e-GP maison Dépassement des coûts None CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 107 ORGANISATION DU PROJET : La Public Procurement and Disposal of Public Assets Authority (PPDA) a réalisé une étude préliminaire pour concevoir le modèle de base de son e-GP. Ensuite, la PPDA a décidé de sélectionner un éditeur de logiciels privé pour développer son e-GP. Après une phase de passation de marché, elle a attribué le développement à European Dynamics. Une équipe TIC (technologies de l’information et de la communication) a été constituée pour travailler en liaison avec l’éditeur de logiciels retenu.19 European Dynamics a supervisé : • La mission de réingénierie des processus d’affaires qui a été menée au début du projet de mise en œuvre. • Définition de la spécification détaillée du système e-GP • La construction du système e-GP Le gouvernement ougandais envisage aujourd’hui de développer un nouveau système d’approvisionnement “maison” (développé en interne). Le budget alloué à ce nouveau projet est d’environ 4 millions de dollars, et le nouveau système e-GP devrait être prêt d’ici 2023. PLANIFICATION DU PROJET Schéma 41 : Planification du projet EPP Étude préliminaire avec Attribution à ED EY pour concevoir le Début de la conception Phase pilote modèle de base et de la construction encore en cours 2014 2015 2016 2017 2018 2019 2020 2021 8 mois 28 mois 24 mois 18 mois Début de la phase Fin de la phase D&B de passation de marchés Début de la phase pilote 2015 : Une étude a été menée en 2015 afin de préciser la solution cible. 2016-2018 : Processus de passation de marché (28 mois) - collecte de tous les besoins fonctionnels, ouverture d’un appel d’offres international, European Dynamics retenu (15 soumissionnaires) 2018 - juillet 2020 : Phase de Design et de Build (20 mois) Juillet 2020 : Début de la phase pilote20 Le statut du projet est actuellement en phase pilote. Le décalage par rapport au calendrier initial est d’environ + 50% 19. https://www.ppda.go.ug/download/ppda_annual_reports/ppda_annual_reports/PPDA-Annual-Report-2017-2018.pdf. 20. https://www.devdiscourse.com/article/other/1174598-uganda-civil-aviation-authority-launches-egp-system-to-unclog-pro- curement-process. 108 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE COUVERTURE FONCTIONNELLE Schéma 42 : Couverture fonctionnelle de l’EPS Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité L’objectif initial était de relier le système au système de paiement et de passerelle e-Tax, au système IFMS, etc. Les interfaces qui ont été développées à ce jour sont : • Intégration avec le système d’enregistrement des entreprises • Intégration avec la passerelle de notification SMS • Intégration avec le système de conformité du fonds de sécurité sociale Il est également rapidement apparu que 35% du montant total du contrat serait consacré au développement d’interfaces pour les 10 instances dirigeantes participant à la phase pilote. Cela signifie qu’il aurait été très coûteux d’étendre le logiciel à tous les pouvoirs adjudicateurs. La direction n’a pas approuvé cette demande de changement. C’est la raison pour laquelle le gouvernement ougandais envisage de développer son propre e-GP “maison”. LES INDICATEURS CLÉS : Les paramètres suivants proviennent de la matrice de collecte de données qui a été envoyée au gouvernement. Les représentants ont confirmé ces informations lors de notre entretien. Nombre total actuel d’utilisateurs enregistrés dans la solution 1 000 Nombre actuel de fournisseurs chargés dans la solution 3 Nombre d’organisations publiques enregistrées dans la solution 10 La plateforme n’est actuellement pas en mesure d’intégrer des fournisseurs. CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 109 COÛTS DU PROJET : Cost repartion during the design and build phase (in K$) Design Project management assistance 99 350 Change requests 200 900 Build Le budget total estimé pour ce projet est de 4,15M$ Le budget total pour la phase de Design et de Build (2018-2020) était de 1,24M$, réparti comme suit : • Design 99K$ • Build : 900K$ • Demandes de changements : 200K$ • Assistance à la gestion de projet 350K$ de gestion de projet Ces chiffres ne tiennent pas compte des coûts internes. Les coûts de fonctionnement annuels payés à European Dynamics s’élèvent à 873 000 $/an (sans les coûts d’hébergement). Cependant, le contrat ayant pris fin en 2021, le gouvernement ougandais n’investira pas davantage dans la maintenance pour les années à venir. RETOUR D’EXPÉRIENCE : Il semble que le gouvernement ougandais ne soit pas entièrement satisfait de sa solution actuelle, et ce pour plusieurs raisons : • Retard par rapport au calendrier initial, en raison du fort besoin de développements spécifiques • Incapacité de développer des interfaces à un coût abordable Afin d’éviter que cela ne se produise, les représentants recommandent les pratiques suivantes pour acquérir un système e-GP : • Détailler les exigences liées à l’intégration avec d’autres systèmes pendant la phase de passation de marché et définir des engagements clairs sur les interfaces dans le contrat. Il est très important que le gouvernement fournisse autant de détails que possible sur les exigences techniques, sur les processus tels qu’ils doivent être reproduits dans l’application et sur les interfaces avec d’autres systèmes. • Mieux vérifier la compréhension et l’interprétation des exigences pendant l’appel d’offres. La procédure d’appel d’offres doit permettre les démonstrations. • L’éditeur de logiciels doit avoir une présence locale dans le pays (cela prend beaucoup de temps de discuter à distance). La proximité permet d’accélérer le projet. Une présence locale aurait beaucoup aidé au transfert de connaissances. La maintenance et le support auraient été plus faciles à gérer. • Clarifier la gouvernance : nécessité d’une structure/organisation de décision unique, qui mettra fin à tous les désaccords. • Faites appel aux services d’une société de conseil spécialisée en gestion de projets informatiques dès le début du projet. 110 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 5.5. Étude de cas n° 4 : l’île Maurice APERÇU DU PROJET MAURICIEN Schéma 43 : Etude de cas e-GP - Ile Maurice AUTORITÉ PUBLIQUE E-GP TYPE DE SOLUTION FOURNISSEUR COTS NEXTENDERS SIFY TECHNOLOGY Bureau des marchés publics CONTEXTE En 2013, le gouvernement de l’île Maurice a sélectionné Nextenders et Sify technology pour développer son système e-GP. Les deux entreprises étaient chargées d’adapter leur système existant et de le maintenir après la mise en œuvre. Il a été décidé de déployer le logiciel avant qu’il ne soit complètement finalisé. Ce dernier a été continuellement amélioré depuis. Le code source est la propriété des fournisseurs. COUVERTURE FONCTIONNELLE Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité PLANNING Attribution du contrat 1ère publication de l’appel d’offres à Nextenders La solution est progressivement Début de la phase de conception déployée, tout en étant 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 mois 48 mois 26 mois Fin de la conception Feuille de route réalisée Début de la phase de construction La solution est entièrement déployée FAITS MARQUANTS COÛT DU PROJET $2,98M Hébergement des données : Coût total depuis - Le système est hébergé sur place, par le gouvernement le début du projet mauricien, sur le cloud gouvernemental. Coût total des phases Autres: de Design & Build $1,45M - Ajout de code hautement spécifique au logiciel coréen d’origine Coûts de (60 % du coût de maintenance est consacré à l’amélioration). fonctionnement annuels $300K - 90% des dépenses d’approvisionnement sont traitées par la solution Dépassement des coûts None CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 111 ORGANISATION DU PROJET : La solution s’appelle EPS. Le type de projet est COTS, basé sur la solution Nextenders (Inde). Le contrat a été attribué à un consortium composé de Nextenders et de Sify Technology. Nextenders et Sify ont été chargés de toutes les phases (conception, développement, tests, formation, conduite du changement) du projet, ainsi que des ressources internes du gouvernement qui ont été affectées à la mise en œuvre de l’EPS. La solution n’a pas été déployée en une seule fois, les modules sont arrivés les uns après les autres, au fur et à mesure de leur développement. Depuis le déploiement de la solution, la maintenance de l’EPS a été confiée à NexTenders en liaison avec le bureau des marchés publics de l’Ile Maurice21. PLANIFICATION DU PROJET : Schéma 44 : Planification du projet EPS Attribution du contrat 1ère publication de l’appel d’offres à Nextenders La solution est progressivement Début de la phase de conception déployée, tout en étant 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 mois 48 mois 26 mois Fin de la conception Feuille de route réalisée Début de la phase de construction La solution est entièrement déployée 2013 : Attribution du marché à Nextenders et Sify Technology 2014 : Conception du modèle de base de la solution, début de la phase de Build, qui devrait durer 18 mois. Septembre 2015 : Déploiement du logiciel, publication du premier appel d’offres. La solution n’est pas encore complète, la feuille de route n’est pas réalisée. Le gouvernement mauricien a décidé de déployer quand même et de continuer à améliorer le logiciel pendant qu’il fonctionne. 2015 - 2017 : Phase de Build, la solution est progressivement déployée lorsque de nouvelles fonctionnalités sont développées et prêtes à être mises en œuvre. juillet 2017 - décembre 2018 : Période de garantie 2019 - maintenant : La feuille de route est réalisée, le modèle original est “ complet “, la solution est entièrement déployée. Elle est encore en cours d’amélioration. Au final, il a fallu 60 mois pour concevoir et développer le modèle de base. Comme la phase de Design et de Build devait durer 18 mois au maximum, le retard est de 230 %. Le retard a été causé par la quantité de personnalisation (développement spécifique) nécessaire pour répondre aux attentes initiales. Aucun problème de gouvernance spécifique n’a été identifié. 21. Mauritius Digital Government Summit 2014 e-procurement System G2G G2B G2C P. Goburdhun Member, Procurement Policy Office 8th October 2014; Organized by the Ministry of Information and Communication Technology, Republic of Mauritius. 112 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE COUVERTURE FONCTIONNELLE : EPS couvre entièrement la phase de pré-attribution. À ce stade, il ne couvre pas les fonctionnalités post-attribution, hormis la gestion des contrats. La solution étant toujours en cours d’amélioration (60 % des frais de maintenance étant alloués au développement de fonctionnalités supplémentaires). En 2020, 2 nouvelles fonctionnalités ont été ajoutées : • Enchères électroniques • Rédaction de contrats EPS n’est interfacé avec aucune autre application/base de données de l’Etat mauricien. L’effort d’intégration avec les outils gouvernementaux (par exemple, les outils comptables et financiers) a été jugé trop important, notamment en raison des capacités d’échange limitées de ces systèmes. Schéma 45 : Couverture fonctionnelle de l’EPS Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité LES INDICATEURS CLÉS : Les données suivantes proviennent de la matrice de collecte de données remplie par le gouvernement mauricien, confirmée par les représentants mauriciens auxquels nous avons parlé. Nombre de fournisseurs enregistrés dans la solution (2020) 3 205 Nombre d’appels d’offres publiés via EPS (2020) 2 750 Économies réalisées grâce à l’utilisation de l’EPS 20% COÛTS DU PROJET : Le coût total du projet est estimé à 2,98M$. La phase de Design et de Build a coûté environ 1,45 M$. Les coûts de fonctionnement annuels sont de 300K$/an (montant total de 1,53M$ depuis le déploiement en 2015). 60 % du coût de la maintenance est affecté aux améliorations. CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 113 Au sein du PPO (Public Procurement Office), une équipe de 12 ETP est dédiée à l’EPS. Cette équipe supervise : • Administration du système • Service d’assistance • SPOC • Formation • Essais • Gestion de projet RETOUR D’EXPÉRIENCE : Un parrainage fort au sein de tous les organes directeurs et un soutien engagé de toutes les parties prenantes sont nécessaires pour réaliser la mise en œuvre de l’e-GP. La gestion du changement est sous-estimée : • À Maurice, de nombreux acheteurs des organes directeurs sont réticents à l’utilisation de des SI, car ils travaillent avec d’autres méthodes depuis plus de 30 ans. • Certains fournisseurs ont également tendance à être réticents, étant donné qu’ils procèdent différemment depuis des années, et que cela rend toutes les procédures de passation de marchés totalement transparentes En ce qui concerne la maintenance de la solution, le contrat/SLA doit prévoir des mécanismes d’escalade en cas d’erreurs récurrentes. 114 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 5.6. Étude de cas n° 5 : Côte d’Ivoire APERÇU DU PROJET : Schéma 46 : Etude de cas e-GP - Côte d’Ivoire AUTORITÉ PUBLIQUE E-GP TYPE DE SOLUTION FOURNISSEUR SIGOMAP Custom N/A Bureau des marchés publics CONTEXTE En Côte d’Ivoire, il existait déjà une base de données publique regroupant tous les marchés publics. L’Office des marchés publics a lancé un projet de développement de l’e-GP en 2019, afin d’étendre le périmètre de celle-ci en concevant le modèle de base de la solution. La Côte d’Ivoire a divisé la couverture fonctionnelle en 2 périmètres qui seront développés sur 2 phases de projet différentes. Le périmètre A couvre l’e-Planification, le périmètre B couvre l’e-Publication à l’e-Attribution. COUVERTURE FONCTIONNELLE Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité PLANNING Début de la phase de conception 2018 2019 2020 2021 24 months La conception du modèle de base est terminée, une étude de faisabilité est actuellement en cours pour estimer les impacts et les exigences techniques pour développer le périmètre A FAITS MARQUANTS COÛT DU PROJET Développement : - Le système sera hébergé hors site, par la SNDI, en Côte d’Ivoire. N/A Coût total depuis le début du projet Hébergement des données : Coût total des phases - La solution est entièrement développée à partir de zéro, avec les de Design & Build N/A ressources internes de l’Office des marchés publics. Coûts de fonctionnement annuels N/A Dépassement des coûts N/A CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 115 ORGANISATION DU PROJET : En mars 2019, le gouvernement ivoirien a lancé un projet e-GP, nommé SIGOMAP. L’outil est destiné à compléter les fonctionnalités de SIGMAP, l’outil de référencement des marchés publics du pays. Le choix s’est porté sur une solution CUSTOM. Le projet est divisé en 2 scopes A et B, qui seront développés successivement. La portée A couvre la planification de l’e-procurement et la portée B couvre le reste du processus S2C, de la publication à l’attribution du contrat. Parallèlement à la phase de Design, une étude d’impact est menée pour identifier les changements induits par le déploiement d’une telle solution, ainsi que les besoins en termes de ressources. Cette étude est toujours en cours. PLANIFICATION DU PROJET : Schéma 47 : Planification du projet SIGOMAP 2018 2019 2020 2021 24 months La conception du modèle de base est terminée, une étude de faisabilité est actuellement en cours pour estimer les impacts et les exigences techniques pour développer le périmètre A Octobre 2019 : Début du projet, collecte des exigences fonctionnelles et conception de la structure de la solution. Rédaction du cahier des charges 2021 : Le modèle de base est conçu, dès lors, une étude de faisabilité/impact est menée pour mettre en œuvre le champ d’application A. COUVERTURE FONCTIONNELLE : La couverture fonctionnelle cible doit être la suivante : • Programmation des achats • Publication en ligne • Appels d’offres en ligne • Evaluation en ligne • Attribution en ligne SIGOMAP est toujours en cours de développement. 116 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE CHIFFRES CLÉS : The are no metrics yet, since the solution has not been deployed. COÛTS DU PROJET : L’équipe interne du gouvernement ivoirien, dédiée au développement de Scope A, est composée de : • Utilisateurs clés, mobilisés pendant 15 mois pour 10% de leur temps • Équipe de développement (7 développeurs à temps plein, 5 de la DGMP, 2 de la SNDI). RETOUR D’EXPÉRIENCE : Les raisons pour lesquelles le gouvernement ivoirien a favorisé le développement CUSTOM sont les suivantes : • Difficultés dans le passé pour faire comprendre aux éditeurs de logiciels les concepts/ processus des marchés publics. • Volonté d’avoir le contrôle total du système du début à la fin. • Volonté de faire évoluer rapidement le SI en fonction des évolutions réglementaires (qui peuvent être nombreuses). Le mode CUSTOM semblait être le plus adapté pour intégrer ces changements et faire évoluer plus rapidement le système e-GP. CHAPITRE V -LE RETOUR D’EXPÉRIENCE I 117 5.7. Accord-cadre SaaS e-GP pour les États du Nigéria Un exemple de déploiement réussi d’un accord-cadre pour les marchés publics GovTech nous vient du Nigeria, où l’autorité des marchés publics de l’État de Kaduna a servi d’acheteur principal et a représenté un groupe d’acheteurs pour acquérir une suite SaaS e-GP22. L’accord-cadre était structuré pour être attribué à un seul fournisseur pour une période de trois ans. En utilisant l’approche de l’accord-cadre, le groupe d’acheteurs a pu rationaliser la procédure de passation de marchés pour l’ensemble des 36 États du Nigeria. En conséquence, au lieu que chaque État gère son propre processus de passation de marchés, tous les États nigérians peuvent passer des contrats d’application (avec les mêmes termes et conditions que ceux énoncés dans l’accord-cadre) avec le fournisseur retenu. 22. Autorité de passation des marchés de l’État de Kaduna, “ Demande d’offres, accord(s)-cadre(s) pour l’acquisition d’un service d’information - logiciel en tant que service “, 18 décembre 2019, http://procurement.edostate.gov.ng/wp-content/uploads/2019/12/ Request-for-Bids.pdf. Conclusion TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 119 Conclusion La plupart des pays africains qui ont lancé des projets e-GP ont choisi de mettre en œuvre soit des solutions CUSTOM, soit des solutions COTS avec une part importante de développements spécifiques. Quatre raisons principales sont généralement invoquées pour justifier cette décision : • Sécurité informatique et sécurité des données • La garantie de souveraineté offerte par ce type de mise en œuvre • La spécificité des processus et des règles de gestion qui rend difficile la mise en œuvre d’un logiciel “pré-packagé”. • La nécessité de faire évoluer plus facilement le système (sans dépendre d’un opérateur privé) Cette enquête a démontré que ce choix n’était pas nécessairement le plus pertinent pour plusieurs raisons : 1 Les projets CUSTOM et COTS avec une forte proportion de développements spécifiques sont identifiés comme les projets les plus complexes et les plus risqués. Ce sont des projets très exigeants pour l’équipe projet gouvernementale. 2 Les projets CUSTOM ou COTS avec une forte proportion de développements spécifiques sont beaucoup plus sensibles au risque de dérive du budget et du planning, Les projets SaaS sont moins sujets à ce risque. Les projets CUSTOM ou COTS avec un poids important de développements spécifiques s’étalent généralement sur plusieurs années en fonction du nombre d’entités publiques concernées et du périmètre fonctionnel retenu. En moyenne, les pays étudiés qui ont opté pour ce type de mise en œuvre ont constaté un écart d’environ 60% par rapport au planning initial. Les difficultés liées à la gouvernance du projet affectent plus fortement ce type de projet et amplifient les dérives de budget et de planning. 3 Il existe des écarts importants entre les ambitions fonctionnelles initiales et les résultats obtenus dans les projets CUSTOM et COTS avec une forte proportion de développements spécifiques. De nombreux éditeurs SaaS spécialisés dans le secteur public proposent désormais des solutions e-GP pré-packagées intégrant la possibilité de s’adapter aux réglementations et contraintes liées aux marchés publics. Ces solutions spécialisées contiennent déjà des fonctionnalités clés pour les gouvernements, telles que la publication en ligne, les appels d’offres en ligne, l’évaluation en ligne, et des fonctionnalités assurant la transparence et l’intégrité des fournisseurs. Ces acteurs ont une grande expérience et leurs solutions ont été testées auprès de nombreux clients publics. Certains éditeurs e-GP ont déjà développé et mis en œuvre des solutions e-GP très complexes dans différents pays. 4 Les coûts de fonctionnement d’une solution CUSTOM (maintenance, évolution, support, hébergement, etc.) sont très élevés par rapport aux solutions SaaS/COTS avec une faible part de développements spécifiques. La maintenabilité d’une solution SaaS est plus élevée grâce à une meilleure gestion des versions des composants, à des modules d’administration robustes et au fait que les coûts soient mutualisés entre les différents clients. 5 Les solutions SaaS et COTS sont supérieures en ce qui concerne la connexion avec des applications tierces, car elles sont dotées d’API “intégrées”, c’est-à-dire de “connecteurs” qui permettent à deux programmes d’échanger des informations. 120 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS CHAPTER V- PUBLICS RETURN ON : OPTIONS EXPERIENCE POUR L’AFRIQUE 6 Les solutions CUSTOM ne sont pas plus sûres. L’enquête a clairement démontré que les éditeurs de logiciels SaaS/COTS déploient beaucoup plus de ressources pour la sécurité des applications et des données que les solutions CUSTOM. En outre, il est très rare que les solutions CUSTOM développées en interne soient auditées par des organismes tiers. 7 L’hébergement des données dans le cloud ne signifie pas nécessairement qu’il n’y a aucune garantie de souveraineté : • Il est techniquement possible que la solution soit hébergée dans un centre de données dans le pays du client. • La plupart des éditeurs d’e-GP proposent une architecture “single-tenant” (multi- instance) qui garantit le partitionnement total des données entre les clients. • Il est possible d’exiger un cryptage des données au niveau du serveur qui rend les données inaccessibles à quiconque ayant un accès physique aux centres de données. Enfin, il est fortement recommandé qu’une phase de préparation soit menée en amont du projet afin de s’assurer que les besoins des différentes entités gouvernementales en matière de passation de marchés soient correctement identifiés et priorisés, ce qui se traduira par : • L’identification et la hiérarchisation des besoins • Une cartographie des processus et des flux de données • Une matrice des avantages et des coûts liés au projet • Un inventaire des applications actuelles utilisées par le gouvernement • Un sourcing précis des fournisseurs qui permet de savoir en amont quels éditeurs d’e-GP seront en mesure de soumettre des offres pertinentes lors de la phase d’appel d’offres. • Un dossier de consultation complet, comprenant des données précises sur : • Les interfaces à développer avec d’autres systèmes • Une estimation précise des entités qui auront accès à la solution et des différents utilisateurs. • Une estimation précise du volume des données opérationnelles qui seront gérées par la solution. Toutes ces informations permettent aux soumissionnaires de fournir un chiffrage pertinent du projet. À l’inverse, des documents d’appel d’offres insuffisamment précis peuvent freiner les réponses des éditeurs de logiciel e-GP. Afin de garantir une préparation complète et de qualité, il est recommandé de faire appel à une société de conseil spécialisée qui apportera une expertise technique et fonctionnelle dans la préparation du projet. TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 121 Références Références dans le chapitre II - Présentation des types de mise en œuvre • Debunking seven common myths about cloud | McKinsey (octobre 2020) • https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/ debunking-seven-common-myths-about-cloud. • Software Development Handbook Transforming for the digital age.pdf | McKinsey (janvier 2016) : • https://www.mckinsey.com/industries/technology-media-and-telecommunications/ our-insights/software-development-handbook-transforming-for-the-digital-age. • Introducing a Commercial Off-The-Shelf Software Solution | OCDE (2019): • https://www.oecd.org/tax/forum-on-tax-administration/publications-and-products/ introducing-a-commercial-off-the-shelf-software-solution.pdf. • https://www.pmi.org/learning/library/custom-off-the-shelf-strategy-6137. • https://www.nbcnews.com/tech/security/ponemon-institute-n364871. • https://www.veracode.com/state-of-software-security-report. • https://cio.economictimes.indiatimes.com/news/digital-security/by-2022-at-least-95-pc- of-cloud-security-failures-will-be-organizations-fault/65438790. • https://analyse-innovation-solution.fr/publication/fr/php/objet-pdo-et-securite-mysql. Références au chapitre III - Étude de marché Site web Appruntheworld, et études : • https://www.appsruntheworld.com/top-10-procurement-software-editors-and-market- forecast/. • https://www.appsruntheworld.com/cloud-top-500/Procurement/. Les réponses des éditeurs de logiciels aux questionnaires de l’étude de marché et les documents supplémentaires qu’ils ont fournis • Veuillez vous référer à l’annexe #2 Réponses des gouvernements africains à la matrice de collecte de données des études de cas • Veuillez vous référer à l’annexe #3 122 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS CHAPTER V- PUBLICS RETURN ON : OPTIONS EXPERIENCE POUR L’AFRIQUE Sites web de éditeurs de logiciels : • http://www.atexo.com/. • https://www.ariba.com/. • https://www.coupa.com/. • https://www.ivalua.com/. • https://www.procuretiger.com/pt/. • https://synertrade.com/en/. • https://www.zycus.com/. • https://www.basware.com/en-en/home/. • https://www.gep.com/. • https://www.neqo.eu/. • https://www.jaggaer.com/. • https://www.bipsolutions.com/. • https://www.procurementexpress.com/. • https://gobonfire.com/. • https://www.eurodyn.com/. • https://www.eauctionservices.com/. • https://marketdojo.com/. • https://www.guadaltel.com/. • https://www.in-tend.co.uk/. • https://www.nextenders.com/. • http://iospartners.com/. Références au chapitre IV - Analyse coûts-avantages Les conclusions sont principalement basées sur les analyses effectuées dans les sections précédentes et sur les études de cas. Quelques ressources documentaires complémentaires ont été utilisées : • https://www.information-age.com/projects-continue-fail-alarming-rate-123470803/ • https://www.objectstyle.com/agile/software-projects-failure-statistics-and-reasons RÉFÉRENCES I 123 Références dans le chapitre V - Retour d’expérience Recherches préliminaires (par pays) RWANDA: • Plate-forme UMYCIO: https://umucyo.gov.rw/. • Banque Mondiale GPPD: https://www.globalpublicprocurementdata.org/gppd/. • https://www.worldbank.org/en/news/feature/2018/09/05/how-rwanda-became-the-first- african-country-with-an-electronic-procurement-system. • Collecte des données Résultats de la matrice (veuillez-vous référer à l’annexe #3) • Entretien avec l’équipe de gestion du projet TUNISIE: • Plate-forme TUNEPS : https://www.tuneps.tn/index.do. • Banque Mondiale GPPD: https://www.globalpublicprocurementdata.org/gppd/. • https://chroniques.tn/2019/05/tuneps-le-nouveau-systeme-tunisien-dachats-publics-en- ligne-obligatoire-a-partir-de-01-septembre-2019/. • https://africanmanager.com/25-musd-de-la-coree-du-sud-pour-le-tuneps-2/ • https://www.oecd.org/mena/governance/improving-e-procurement-environment-tunisia-fr.pdf. • https://www.webmanagercenter.com/2014/06/18/151461/tunisie-marches-publics-tuneps- tn-une-avancee-dans-la-bonne-gouvernance/. • Collecte des données Résultats de la matrice (veuillez-vous référer à l’annexe #3) • Entretien avec l’équipe de gestion du projet OUGANDA: • Portail des marchés publics (GPP) : https://gpp.ppda.go.ug/. • Banque Mondiale GPPD: https://www.globalpublicprocurementdata.org/gppd/. • https://www.devdiscourse.com/article/other/1174598-uganda-civil-aviation-authority- launches-e-GP-system-to-unclog-procurement-process. • PPDA Annual report 2018: https://www.ppda.go.ug/download/ppda_annual_reports/ppda_ annual_reports/PPDA-Annual-Report-2017-2018.pdf. • Collecte des données Résultats de la matrice (veuillez-vous référer à l’annexe #3) • Entretien avec l’équipe de gestion du projet 124 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE L’ÎLE MAURICE : • SYSTÈME DE PROCURATION EN LIGNE DU GOUVERNEMENT DES MAURICE : https://eproc.publicprocurement.govmu.org/. • Banque Mondiale GPPD: https://www.globalpublicprocurementdata.org/gppd/. • Mauritius Digital Government Summit 2014 e-procurement System G2G G2B G2C, presented by P. Goburdhun. Member, Procurement Policy Office 8th October 2014; Organized by the Ministry of Information and Communication Technology, Republic of Mauritius. • Collecte des données Résultats de la matrice (veuillez-vous référer à l’annexe #3) • Entretien avec l’équipe de gestion du projet CÔTE D’IVOIRE : • Banque Mondiale GPPD: https://www.globalpublicprocurementdata.org/gppd/. • Collecte des données Résultats de la matrice (veuillez-vous référer à l’annexe #3) • Entretien avec l’équipe de gestion du projet LISTE DES PERSONNES INTERROGÉES PAR PAYS : PAYS INTERVIEES FONCTION Rwanda Public Procurement Authority Francine Gatarayiha e-Procurement Project Manager Rwanda Public Procurement Authority RWANDA Celestin Sibomana Manager, Research, Capacity Development and Monitoring Rwanda Public Procurement Authority Jean-Luc Ziravuga Purchase manager for e-procurement Khaled El Arbi President of the High Authority for Public Procurement Sonia Ben Salem e-Procurement Unit Director Rim Zehri Director General of the National Observatory of Public Procurement Sonia Ben Salem Director General of the TUNEPS Unit TUNISIE Controller of Public Procurement, Head of Department at the Manel Nasri TUNEPS Unit Nizar Abdelli Chief Controller of Public Procurement, Director of the TUNEPS Unit Sawsen Naccache Head of Department at the TUNEPS Unit TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 125 PAYS INTERVIEES F0NCTION Public Procurement and Disposal of Public Assets Authority Benson Turamye Director Public Procurement and Disposal of Public Assets Authority Florence Nakyeyune Project Manager OUGANDA Ministry of Finance, Planning and Economic Development David Kiyingi Nyimbwa Commissioner, Procurement Policy and Mgt. Dept Ministry of Finance, Planning and Economic Development Lawrence Semakula Accountant General Hirendranath Procurement Policy Office Rambhojun Director Procurement Policy Office L’ÎLE MAURICE Gawesh Jawaheer Project Manager e-Procurement System / IT Consultant Bhagwansing Procurement Policy Office Dabeesing Member Information, Training and Communication Systems Ahoua Ouattara Director Anassin Sylvie Patricia Information, Training and Communication Systems CÔTE D’IVOIRE AYE Chief Operating Officer Statistics and Studies Amadou Bokoum Director 126 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Annexe 1 Fiche de synthèse pour chaque développeur de logiciel Atexo IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC ATEXO FRANCE 70 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 100% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Gouvernement de France Phase de pré-attribution (93%) Phase post-attribution (42%) Fonctionnalités d’appui (61%) Pays: France Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 2 000 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : France Précision sur le modèle financier : Editeur Integrateur Mixte Fournisseur de services d’hébergement : OVH • Nombre d’appels d’offres Certification Audit • Quantité de données stockées Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte ISO27001; PCI-DSS, SOC 1 Type II, SOC 2 Type II Bip Solutions IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC BIP SOLUTIONS ROYAUME-UNI 174 EN AFRIQUE Moyen OUI % of du chiffre d’affaires : 50% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Gouvernement de Lebanon Phase de pré-attribution (60%) Phase post-attribution (10%) Fonctionnalités d’appui (32%) Pays: Lebanon Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 2 000 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Gouvernement des Bahamas Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Les Bahamas Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 300 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Dubai Expo Signature électronique Pays: EAU Année: N/A Filtres d’intégrité Budget: 1 600 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : France Précision sur le modèle financier : Fournisseur de serv. d’héb. : BIP servers Editeur Integrateur Mixte • N/A Certification Audit Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte ISO27001; ISO9001 ANNEXE 1 : FICHE DE SYNTHÈSE POUR CHAQUE DÉVELOPPEUR DE LOGICIEL I 127 Bonfire IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC BONFIRE CANADA 100 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 100% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Cayman Islands Government Phase de pré-attribution (68%) Phase post-attribution (15%) Fonctionnalités d’appui (50%) Pays: Cayman Islands Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 450 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Texas Dept. of Transportation Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: USA Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 250 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Delaware Dept. of Social Services Signature électronique Pays: USA Année: N/A Filtres d’intégrité Budget: 45 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’héb. : Canada, Etats-Unis, Alemagne Précision sur le modèle financier : Editeur Integrateur Mixte Fournisseur de serv. d’hébergement : AWS • Bonfire propose une facture unique sur une base Certification Audit annuelle pour le service d’abonnement ; toutefois, les Main d’œuvre run Certification de l’État annuel agences peuvent payer la totalité de la durée en avance Editeur Integrateur Mixte SOC 2 Type II à un taux réduit. Le prix de la license est basé sur le nombre d’utilisateurs. EASIBUY IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC EASIBUY ETATS-UNIS 15 EN AFRIQUE Moyen - Fort OUI % of du chiffre d’affaires : 80% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Gouvernement des îles Caïmans Phase de pré-attribution (87%) Phase post-attribution (15%) Fonctionnalités d’appui (86%) Pays: Îles Caïmans Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 180 000 $ / an Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Ville de Los Angeles Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Etats-Unis Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 300 000 $ / an Evaluation et attribution en ligne Gestion des litiges Client: État du Connecticut Signature électronique Pays: Etats-Unis Année: N/A Filtres d’intégrité Budget: 300 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Etats-Unis Précision sur le modèle financier : Fournisseur de serv. d’hébergement : AWS Editeur Integrateur Mixte • Mensuel par utilisation Certification Audit • Le prix des licenses dépend du nombre d’offres Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte AWS certifications 128 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE European Dynamics IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC EUROPEAN GRÈCE 650 EN AFRIQUE Fort DYNAMICS OUI % of du chiffre d’affaires : 100% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Aut. des marchés publics de Zambie Phase de pré-attribution (95%) Phase post-attribution (90%) Fonctionnalités d’appui (82%) Pays: Zambie Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 2 100 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: PPRA du Gouvernement de Tanzanie Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Tanzanie Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 1 700 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Min. Comm. Gouvernement de Ghana Signature électronique Pays: Ghana Année: N/A Filtres d’intégrité Budget: 2 400 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Grèce Précision sur le modèle financier : Fournisseur de serv. d’héb. : ED datacenters Editeur Integrateur Mixte • Prix de la license basé sur le nombre d’utilisateurs / Certification Audit pouvoirs adjudicateurs Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte ISO27001 GEP IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC GEP INDE 1200 EN AFRIQUE Moyen OUI % of du chiffre d’affaires : N/A COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: University of California Phase de pré-attribution (100%) Phase post-attribution (100%) Fonctionnalités d’appui (96%) Pays: Etats-Unis Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 14 000 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : N/A Précision sur le modèle financier : Editeur Integrateur Mixte Fournisseur de serv. d’héb. : Microsoft Azure • Le montant de l’abonnement annuel dépend du nombre Certification Audit d’utilisateurs par modules mise en œuvre, et du nombre Main d’œuvre run Certification de l’État annuel de fornisseurs Editeur Integrateur Mixte SOC1 and SOC2 SSAE 16 / ISAE 3402 ; ISO / IEC 27001:2005 ANNEXE 1 : FICHE DE SYNTHÈSE POUR CHAQUE DÉVELOPPEUR DE LOGICIEL I 129 Guadaltel IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC GUADALTEL ESPAGNE 240 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 98% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Fédération espagnole des municipalités Phase de pré-attribution (75%) Phase post-attribution (36%) Fonctionnalités d’appui (46%) Pays: Espagne Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 450 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Mairie de Barcelona Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Espagne Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 2 000 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Mairie de Sevilla Signature électronique Pays: Espagne Année: N/A Filtres d’intégrité Budget: 1 500 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Irlande Précision sur le modèle financier : Fournisseur de serv. d’hébergement : AWS Editeur Integrateur Mixte • Aucune information sur le modèle de tarification Certification Audit Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte Amazon certifications In-tend IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC IN-TEND ROYAUME-UNI 35 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 95% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Min. des Finances, Cr. économique Phase de pré-attribution (100%) Phase post-attribution (50%) Fonctionnalités d’appui (82%) Pays: St Lucia Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 110 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: European Union (R. des Capacités) Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Somalie Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 200 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Nations Unies Signature électronique Pays: N/A Année: N/A Filtres d’intégrité Budget: 500 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Royaume-Uni Précision sur le modèle financier : Editeur Integrateur Mixte Fourn. de serv. d’héb. : In-tend’s datacenters • License 1ère année plus frais d’hébergement annuels, Certification Audit basés sur le nombre d’appels d’offres, de contrats, de Main d’œuvre run Certification de l’État annuel commandes d’achat traités par le logiciel. Également Editeur Integrateur Mixte ISO 27001/22301/9001 basé sur la quantité de données stockées 130 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE IOS Partners IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC IOS PARTNERS ETATS-UNIS 40 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 90% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: IFC et Banque Mondiale Phase de pré-attribution (100%) Phase post-attribution (44%) Fonctionnalités d’appui (46%) Pays: Malawi, Moldavie, et Lettonie Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 300 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Etats-Unis Précision sur le modèle financier : Fourn. de serv. d’héb. : Micr. Azure, Rackspace Editeur Integrateur Mixte • Les facteurs de prix dépendent du type de solution Certification Audit (COTS/SaaS) Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte ISO27001, CMMI-LIII Ivalua IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC IVALUA FRANCE 635 EN AFRIQUE Moyen OUI % of du chiffre d’affaires : N/A COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Ville de New York Phase de pré-attribution (100%) Phase post-attribution (100%) Fonctionnalités d’appui (100%) Pays: Etats-Unis Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: N/A Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Etats-Unis, Europe, Canada Précision sur le modèle financier : Editeur Integrateur Mixte F. de serv. d’héb. : Micr. Azure, Equinix, Aptum • Prix de l’abonnement basé sur le nombre d’utilisateurs Certification Audit par modules activés Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte ISO 9001/14001/27001, SOC 1 Type II, SOC 2 Type II ANNEXE 1 : FICHE DE SYNTHÈSE POUR CHAQUE DÉVELOPPEUR DE LOGICIEL I 131 Market Dojo IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC MARKET DOJO ROYAUME-UNI 35 EN AFRIQUE Moyen - Faible OUI % of du chiffre d’affaires : 12% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Conseil du comté de Kent Phase de pré-attribution (65%) Phase post-attribution (9%) Fonctionnalités d’appui (21%) Pays: Royaume-Uni Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 10 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Conseil de l’arrondiss. de Bedford Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Royaume-Uni Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 10 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Creative Education Signature électronique Pays: Royaume-Uni Année: N/A Filtres d’intégrité Budget: 3 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : N/A Précision sur le modèle financier : Fourn. de serv. d’héb. : Google Cloud Platform Editeur Integrateur Mixte • Options de prix flesibles Certification Audit • Le prix de la license dépend du nombre d’utilisateurs Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte ISO27001 Marketplanet IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC MARKETPLANET POLOGNE 80 EN AFRIQUE Moyen - Faible OUI % of du chiffre d’affaires : 22% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Centre de services admin. Phase de pré-attribution (100%) Phase post-attribution (80%) Fonctionnalités d’appui (50%) Pays: Pologne Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 200 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Pologne Précision sur le modèle financier : Editeur Integrateur Mixte Fournisseur de services d’héb. : Orange • Le prix de la license est basé sur le nombre Certification Audit d’utilisateurs, es bons de commande, la quantité de Main d’œuvre run Certification de l’État annuel données stockées, la puissance de calcul utilisé et le Editeur Integrateur Mixte TBD nombre d’environnements achetés. 132 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE NEQO IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC NEQO FRANCE 12 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 100% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: DAE (Min. de l’Économie) Phase de pré-attribution (60%) Phase post-attribution (20%) Fonctionnalités d’appui (54%) Pays: France Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 150 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Région Bretagne Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: France Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 120 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Min. Belge de l’Économie Signature électronique Pays: Belgique Année: N/A Filtres d’intégrité Budget: 25 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : France Précision sur le modèle financier : Editeur Integrateur Mixte Fourn. de services d’héb. : OVH, Clevercloud • Le prix de la license dépend du nombre d’utilisateurs et Certification Audit des champs de fonctionnalités associés (six champs de Main d’œuvre run Certification de l’État annuel fonctionnalités au total) Editeur Integrateur Mixte ISO27001 ; PCI-DSS, SOC 1 Type II, SOC 2 Type II Nextenders IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC NEXTENDERS INDE 40 EN AFRIQUE Fort OUI % of du chiffre d’affaires : 95% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Min. des Finances et du Dev. Éc. Phase de pré-attribution (100%) Phase post-attribution (100%) Fonctionnalités d’appui (86%) Pays: Maurice Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 2 991 109 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Commission des Marchés Publics Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Botswana Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 1 541 464 $ Evaluation et attribution en ligne Gestion des litiges Client: Dépt. du Budget et de la Gestion Signature électronique Pays: Philippines Année: N/A Filtres d’intégrité Budget: 2 920 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Inde, Singapour Précision sur le modèle financier : F. de serv. d’héb. : Amazon AWS, Micr. Azure Editeur Integrateur Mixte • Le prix de la license est basé sur le nombre de Certification Audit fournisseurs, d’appels d’offres, de contrats signés et de Main d’œuvre run Certification de l’État annuel bons de commande. Editeur Integrateur Mixte ISO 27001; STQC ANNEXE 1 : FICHE DE SYNTHÈSE POUR CHAQUE DÉVELOPPEUR DE LOGICIEL I 133 ProcurementExpress.com IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC PROCUREMENT IRLANDE 25 EN AFRIQUE Moyen - Faible EXPRESS.COM OUI % of du chiffre d’affaires : 10% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Comté de Davies Phase de pré-attribution (13%) Phase post-attribution (75%) Fonctionnalités d’appui (32%) Pays: Etats-Unis Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 5 000 $ / an Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Etats-Unis, Europe Précision sur le modèle financier : Fourn. de serv. d’héb. : Amazon AWS Editeur Integrateur Mixte • Le prix de la license est basé sur nombre d’utilisateurs Certification Audit Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte Procure Tiger IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC PROCURE INDE 200 EN AFRIQUE Moyen TIGER OUI % of du chiffre d’affaires : 25% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Gouvernement de Bangladesh Phase de pré-attribution (68%) Phase post-attribution (15%) Fonctionnalités d’appui (50%) Pays: Bangladesh Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 2 450 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Bharat Petroleum Corp. Ltd. Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: India Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: 1 150 000 $ Evaluation et attribution en ligne Gestion des litiges Client: Corporation municipale de Pune Signature électronique Pays: India Année: N/A Filtres d’intégrité Budget: 350 000 $ TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Inde Précision sur le modèle financier : Editeur Integrateur Mixte Fourn. de serv. d’héb. : CtrlS Data Center • Le prix de la license dépend des modules choisis, à savoir Certification Audit les demandes d’achat, les appels d’offres électroniques, Main d’œuvre run Certification de l’État annuel les enchéres, la gestion des contrats, etc. Editeur Integrateur Mixte ANSI TIA 942 A ; ISO 9001/22301/27001/270018, etc. • License perpétuelle, paiement par événement, fournis- seur payeur, commission en %, etc. 134 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Synertrade IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC SYNERTRADE ETATS-UNIS 360 EN AFRIQUE Moyen OUI % of du chiffre d’affaires : N/A COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Groupe de la Banque Mondiale Phase de pré-attribution (100%) Phase post-attribution (100%) Fonctionnalités d’appui (82%) Pays: Etats-Unis Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: 2 500 000 $ Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : Alemagne, Etats-Unis Précision sur le modèle financier : Editeur Integrateur Mixte Fourn. de serv. d’héb. : Noris Net., Rackspace • Le prix de la license est basé sur le nombre d’offres, de Certification Audit contrats signés et de bons de commande Main d’œuvre run Certification de l’État annuel Editeur Integrateur Mixte SOC 2 Type I, SOC 2 Type II and ISO 9001, ISO 27001 uStudio IDENTITÉ DU FORNISSEUR NOM PAYS # D’EMPLOYÉS CAPACITÉ DE MISE EN ŒUVRE INTÉRÊT POUR LE SECTEUR PUBLIC USTUDIO UKRAINE 27 EN AFRIQUE Moyen OUI % of du chiffre d’affaires : 25% COUVERTURE FONCTIONNELLE EXPÉRIENCE SIGNIFICATIVE Client: Min. du Dev. Économique Phase de pré-attribution (77%) Phase post-attribution (59%) Fonctionnalités d’appui (39%) Pays: Ukraine Année: N/A Programmation des achats en ligne Gestion des contrats Portail fournisseurs Budget: N/A Publication en ligne/Notification E-catalogues Gestion des fournisseurs Client: Transparency International Ukraine Appel d’offres en ligne Gestion des catalogues Recherches transverses Pays: Ukraine Année: N/A Enchères inversées Gestion des DA Suivi et rapports Budget: N/A Evaluation et attribution en ligne Gestion des litiges Client: State of Connecticut Signature électronique Pays: Moldavie Année: N/A Filtres d’intégrité Budget: N/A TYPE DE MISE EN OEUVRE HÉBERGEMENT ET SÉCURITÉ DES DONNÉES MODÈLE DE TARIFICATION Custom COTS SaaS Sur site Hors site Frais d’abonnement Licence logicielle perpétuelle Main d’œuvre build Lieu d’hébergement : N/A Précision sur le modèle financier : Fournisseur de serv. d’hébergement : N/A Editeur Integrateur Mixte • Forfait por le développement et la mise en œuvre Certification Audit • Une redevance plus faible pour les 12 mois de Main d’œuvre run Certification de l’État annuel maintenance d’une version de base tout en l’améliorant Editeur Integrateur Mixte avec des fonctionnalités avancée TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 135 Annexe 2 Questionnaire d’étude de marché Cette section présente la traduction du questionnaire transmis aux éditeurs du marché des suites d’achat dans le cadre de l’enquête auprès des fournisseurs (questionnaire uniquement transmis en Anglais). Le questionnaire est divisé en 5 parties : 1 Un onglet “Entreprise”, dans lequel les fournisseurs peuvent décrire certaines des caractéristiques de leur entreprise. 2 L’onglet “Couverture fonctionnelle”, dans lequel les fournisseurs ont décrit les fonctionnalités que leur solution couvre, par rapport à la couverture fonctionnelle totale de l’e-GP telle qu’imaginée par la banque. 3 L’onglet “Mise en œuvre”, dans lequel les développeurs du logiciel présentent les méthodes de déploiement de la solution, ainsi que leur méthodologie. 4 L’onglet “Hébergement et sécurité”, dans lequel les vendeurs présentent les méthodes d’hébergement de leur solution, ainsi que diverses caractéristiques de leur offre liées à la sécurité. 5 Enfin, l’onglet “Modèle financier”, dans lequel les fournisseurs présentent le mode d’acquisition de leur solution. “Section” Entreprise DES INFORMATIONS SUR VOTRE ENTREPRISE 1. PROFIL DE L’ENTREPRISE Nom Année d’incorporation Chiffre d’affaires en 2019 (en K$) Chiffre d’affaires en 2020 (en K$) Chiffre d’affaires prévisionnel pour 2021 (en K$) Pourcentage des revenus générés par les clients publics Nombre d’employés 2. REFERENCES 1. Veuillez remplir le tableau suivant avec des exemples de projets auxquels vous avez participé. 2. Vous pouvez ajouter autant de lignes que vous le jugez pertinent Description du projet Pays Client Budget (portée, caractéristiques dans cette section. nom (K$) principales, planification) 3. Veuillez mettre l’accent sur votre expérience dans les pays africains, le cas échéant. Expérience dans la mise en œuvre d’une solution de passation de marchés publics en ligne (système d’information sur les achats spécifiquement conçu pour les organismes gouvernementaux et les marchés publics). Expérience dans la mise en œuvre de solutions d’approvisionnement/achat en ligne dans des organisations privées. 3. SECTEUR PUBLIC Quelles sont les grandes tendances que vous observez sur le marché des solutions de marchés publics en ligne ? Quelles sont vos priorités stratégiques en ce qui concerne le secteur public ? (principales caractéristiques à développer, partenariats, ...) 4. LOCALISATION Où sont basés les centres de développement (R&D) ? Où sont situés vos bureaux de vente ? 136 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Section “Couverture fonctionnelle” COUVERTURE FONCTIONNELLE de votre solution e-GP Informations sur votre solution de passation de marchés en ligne Nom de la solution Commercialisé depuis (année) ? Liste de tous les clients publics utilisant la solution La solution est-elle basée sur une source ouverte ? Soutenu par S’il n’est pas pris en charge la solution ? par la norme, il peut être (sélectionnez ajouté avec un code spécifique Caractéristiques Oui ou Non) (sélectionnez Oui ou Non) Phase de pré-adjudication 1. Planification des achats en ligne 1.1 Préparation de projets d’achat (recueil des besoins, planification, stratégie, etc.) 1.2 Approbation du projet d’achat (workflow) 1.3 Regroupement / consolidation des projets dans des programmes ou des plans 2. Publication en ligne /Notification 2.1 Création d’un espace de travail pour les appels d’offres et configuration du flux de travail 2.2 Attribuer les appels d’offres aux acheteurs et gérer la charge de travail de « l’équipe » 2.3 Préparation des documents d’appel d’offres (y compris les modèles, la rédaction, ...) 2.4 Préparation du questionnaire d’appel d’offres 3. e-Tendering (from the supplier’s perspective) 3.1 Soumission des questions par le fournisseur, lecture des réponses 3.2 Création et soumission d’offres 3.3 Sécurité des offres (confidentialité, accusé de réception, etc.) 4. e-Evaluation/e-Attribution 4.1 Gestion des dates d’ouverture/fermeture des offres 4.2 Évaluation des offres (financières et techniques) 4.3 Assistance à la procédure d’attribution 5. Enchères électroniques inversées 5.1 Enchères électroniques inversées (anglais, néerlandais, japonais) Phase post-attribution 6. Planification des achats en ligne 6.1 Référentiel des contrats 6.2 Autorisation et approbation du contrat 6.3 Gestion des négociations, des modifications et des renouvellements de contrats (y compris les notifications) 6.4 Gestion des indicateurs clés de performance sur les contrats 6.5 Contrôle des dépenses sur les contrats 7. Catalogues en ligne 7.1 Gestion de l’espace de travail du catalogue 7.2 Parcourir le catalogue 7.3 Gestion des paniers 8. Gestion des catalogues 8.1 Préparation du catalogue 8.2 Présentation du catalogue 8.3 Approbation du catalogue 8.4 Version du catalogue 8.5 Activation du catalogue 9. Achats en ligne 9.1 t Demande d’emploi 9.2 Devis 9.3 Bon de commande 9.4 Facture 9.5 Paiement 9.6 Bon de réception des marchandises ANNEXE 2 : QUESTIONNAIRE D’ÉTUDE DE MARCHÉ I 137 Caractéristiques de soutien 10. Enregistrement en ligne 11. Gestion des fournisseurs 11.1 Informations générales sur le vendeur (exigences légales) 11.2 Stockage de documents juridiques 11.3 Gestion de la performance des fournisseurs 11.4 Plaintes et réclamations du fournisseur 12. Recherche transversale 13. Suivi et rapports 13.1 Notifications et alertes 13.2 Pistes d’audit : possibilité d’associer toute transaction à une source documentaire 13.3 Rapports et tableaux de bord d’intelligence économique 13.4 Norme ouverte de données contractuelles (OCDS) 14. Plaintes en ligne 15. Signature électronique 16. Filtres d’intégrité 17. Capacités d’intégration des données 17.1 Veuillez détailler vos capacités en termes d’intégration et d’interopérabilité des données (EAI, ETL, ...). 138 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Section “Mise en œuvre” PRATIQUES EN MATIÈRE DE MISE EN ŒUVRE ET D’AIDE Veuillez sélectionner N’hésitez pas à ajouter une réponse des commentaires Quel est le mode de mise en œuvre de la solution ? Custom • Modèle SaaS COTS • ou Commercial-Off-The-Shelf (COTS) SaaS • ou CUSTOM ? Où sont basés les ressources/services qui soutiennent les phases de “DESIGN” et de “BUILD” d’un projet de mise en œuvre ? (Pays) Pensez-vous avoir la capacité d’intervenir dans les pays africains ? Avez-vous des partenaires certifiés en Afrique pour vous aider dans la mise en œuvre technique ? (si oui, indiquez les noms) Veuillez décrire la répartition typique des rôles pendant les phases de conception et de construction (répartition des rôles entre le fournisseur informatique, l’intégrateur, le fournisseur, le client, ...). Exemple : • Qui est en charge des ateliers de spécification (ateliers fonctionnels, core model...) ? L’éditeur ou l’intégrateur ? • Quels types d’interlocuteurs sont nécessaires du côté de l’ad- ministration ? Dans quel but ? • Qui est en charge des tests ? • Qui est en charge de la gestion du changement ? Veuillez décrire la distribution typique des rôles dans la phase RUN (maintenance, support, évolutions). Exemple : • Qui est en charge du support utilisateur de niveau 1 ? Du support utilisateur de niveau 2 ? Editeur ou Intégrateur ? Les deux ? • Qui est en charge du développement des petites améliorations ? Editeur ou Intégrateur ? Les deux ? Informations supplémentaires que vous souhaitez partager ANNEXE 2 : QUESTIONNAIRE D’ÉTUDE DE MARCHÉ I 139 Section “Hébergement et sécurité” CARACTÉRISTIQUES TECHNIQUES, D’HÉBERGEMENT ET DE SÉCURITÉ DE VOTRE SOLUTION e-GP 1. LES NAVIGATEURS PRIS EN CHARGE ET LES APPAREILS Liste des navigateurs certifiés compatibles avec la solution (testés et approuvés par le fournisseur) La solution est-elle compatible avec les appareils mobiles ? 2. Hébergement des données Localisation des installations du centre de données (Pays) Nom du ou des fournisseurs de services d’hébergement sur lesquels vous comptez (MS Azure, Amazon, OVH...) Liste des certifications obtenues par votre/vos fournisseur(s) de services d’hébergement Veuillez fournir des détails sur la sécurité physique de l’hébergement (contrôles d’accès, gardes, racks dédiés et verrouillés, alimentation électrique, ventilation, sécurité incendie). Veuillez fournir des détails sur la sécurité de l’accès au serveur (IPSc, VPNs...) Votre solution e-GP a-t-elle déjà été mise en œuvre sur place ? (Solution installée et fonctionnant sur des ordinateurs dans les locaux de l’organisation qui utilise le logiciel, plutôt que sur un site distant tel qu’une grappe de serveurs ou un nuage). Si vous avez déjà mis en œuvre votre solution sur site, veuillez décrire comment vous procédez (partage de la responsabilité avec le client, exigences techniques pour que l’application fonctionne, etc.) Accepteriez-vous de considérer l’option “sur site” ? (solution installée et fonctionnant sur des ordinateurs dans les locaux de l’organisation qui utilise le logiciel, plutôt que dans une installation distante telle qu’une ferme de serveurs ou un nuage). Dans le cas d’une mise en œuvre sur site, quel serait le pourcentage approximatif de la majoration des coûts de projet/maintenance ? (en %) Informations supplémentaires que vous souhaitez partager 3. Sécurité des applications L’architecture technique et la sécurité de la solution ont-elles déjà été auditées et certifiées par un État ? Si oui, lequel ou lesquels ? Liste des certificats de conformité relatifs à la gestion de la sécurité Les pratiques en matière de sécurité, d’identification et d’authentification des applications sont-elles auditées chaque année par des organismes indépendants ? Si oui, lequel ou lesquels ? Informations supplémentaires que vous souhaitez partager 140 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Section “Modèle financier” MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP 1. Licences SaaS COTS Sur mesure* Quel est votre modèle de tarification standard pour les licences : SaaS COTS - Un modèle d’abonnement (sur une base trimestrielle par exemple) ? *Si votre entreprise développe des solutions - Une licence de logiciel (payée d’avance en une seule fois) ? personnalisées, veuillez - Autre ? (veuillez préciser) passer directement à la section 3. Êtes-vous en mesure de proposer les deux modèles ? Le coût de la licence dépend-il de : SaaS COTS Commentaires - Nombre d’utilisateurs (appartenant à l’organisation cliente) ? - Nombre de fournisseurs ? - Nombre d’offres ? - Nombre de contrats signés ? - Nombre de bons de commande ? - Quantité de données stockées ? - La puissance de calcul utilisée ? De quels autres paramètres dépend le prix des licences ? SaaS COTS A votre avis, quel est le “prix du marché” approximatif des licences ? • 20 Ministères • Utilisateurs intensifs (création d’appels d’offres...) : 250 • Appels d’offres (par an) : 1500 • Lecture seule et validateurs : 1000 • Fournisseurs : 5000 • selon les métriques listées (fourchette de prix en K$) • et pour tous les modules couvrant la phase de pré-attribution et K$ K$ les fonctionnalités de reporting (fonctionnalités 1 à 4, 10, 11 et 13 dans la feuille excel “Couverture fonctionnelle”) Commentez si votre couverture fonctionnelle est différente de celle spécifiée à gauche. 2. Coûts de mise en œuvre pour COTS et/ou SaaS SaaS COTS Commentaires A votre avis, quel serait le coût total estimé en k$ pour les phases de “design” et de “build” : • sur la base du même périmètre fonctionnel (fonctionnalités 1 à 4, 10, 11 et 13 dans la feuille Excel “Functional coverage”) K$ K$ • sans le coût des interfaces et de la migration des données historiques • et compte tenu des métriques du projet fournies ci-dessus. À votre avis, quelle serait la durée approximative du projet (phases de conception et de construction), en mois ? Selon vous et sur la base de votre expérience, quels sont les principaux risques d’un tel projet ? Quelles sont les meilleures pratiques que vous recommanderiez dans le cadre de la mise en œuvre de la solution e-GP ? ANNEXE 2 : QUESTIONNAIRE D’ÉTUDE DE MARCHÉ I 141 3. Section UNIQUEMENT dédiée aux “fournisseurs de solutions personnalisées” (pas pour les éditeurs de SaaS / COTS) Quel a été le budget de mise en œuvre (en k$) des précédents projets de développement menés par votre société couvrant la phase de pré-adjudication et les fonctionnalités de reporting (fonctionnalités 1 à 4, 10, 11 et 13 dans la feuille Excel “Couverture K$ fonctionnelle”) (à l’exclusion des interfaces et de la migration des données historiques) ? Quelle a été la durée du projet en mois ? Quelles sont les meilleures pratiques que vous recommanderiez dans le cadre de la mise en œuvre de la solution e-GP ? 142 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Annexe 3 Matrice de collecte des données La matrice de collecte de données est le document envoyé à tous les gouvernements africains afin de prendre note de l’état d’avancement de leurs projets e-GP (pour ceux qui ont déjà mis en œuvre un e-GP ou qui souhaitent le faire dans les années à venir). Cette matrice est composée de plusieurs sections : • Identité du projet”, dans laquelle des informations générales sur le projet sont demandées (dates, type, fournisseurs, propriété de la gestion du projet, etc.) • “Couverture fonctionnelle”, dans lequel les gouvernements décrivent la couverture fonctionnelle de leur système e-GP en place ou en cours de développement. • La “complexité de l’intégration”, dans laquelle les gouvernements décrivent les systèmes avec lesquels leur e-GP est interfacé, ainsi que la difficulté de développer les interfaces. • Les “métriques du système”, dans lesquelles les gouvernements fournissent des indications chiffrées relatives à l’adoption, l’utilisation et les avantages de leur système e-GP. • “Planification de la mise en œuvre du système”, dans laquelle les gouvernements présentent le planning projet et de déploiement de leur e-GP, en mentionnant les retards possibles. • “Coût du projet”, qui permet de déclarer le budget total du projet et de ventiler les coûts en fonction des différentes phases et chantiers. • “Hébergement des données”, dans lequel les gouvernements décrivent comment leur e-GP est ou sera hébergé. ANNEXE 3 : MATRICE DE COLLECTE DES DONNÉES I 143 Bonnes pratiques et points de vigilance à considérer : A. Identité Nom du système e-GP URL du système e-GP Pays Type de mise en œuvre (Custom, Cots, SaaS) Date de début du projet (date d’attribution du marché au fournisseur / développeur de la solution) Langue supportée 1 Langue supportée 2 Langue supportée 3 Langue supportée 4 Langue supportée 5 Devise supportée 1 Devise supportée 2 Devise supportée 3 Devise supportée 4 Devise supportée 5 Projet fondé sur l’Open Source ? Code du Projet Banque Mondiale Nom du Projet Banque Mondiale Statut du Projet Banque Mondiale (Pipeline, Active, Closed) Montant du Projet Banque Mondiale Budget dédié aux composants e-GP Système utilisé par la Banque Mondiale e-Procurement System used by the World Bank (Oui/Non) Méthodes de passation de marchés de la Banque Mondiale supportées par le système (RFQ/NCB/ICB/autre) (si autres, commentez, s’il-vous-plaît) Fournisseur / Développeur de la solution Noms des fournisseurs Intégrateur et détails de l’organisation du projet Responsable de la gestion du projet Autre Accords sur le niveau de service (SLA) (En plus de vos commentaires, vous pouvez fournir tout document détaillant le projet.) 144 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE B. Couverture fonctionelle Oui, Non, En cours de développement, Planifié dans les 2 ans à venir Phase pré-attribution Plan de passation des marchés publics en ligne (e-Procurement Planning) Publication /notification électronique (e-Publication/Notification) Appel d’offres électronique (e-Tendering) Enchères électroniques inversées (e-Reverse Auction) Évaluation/Attribution électronique (e-Evaluation/Awarding) Phase post-attribution Gestion électronique des contrats (e-Contract management) Catalogues électroniques (e-Catalogues) Gestion électronique des catalogues (e-Catalogue Management) Achats électroniques (e-Purchasing) Fonctionnalités support Enregistrement électronique (e-Registration) Gestion électronique des fournisseurs (e-Vendor management) Recherche transversale Suivi et rapports sur les marchés publics (Monitoring and reporting) Plaintes électroniques (e-Complaints) e-Signature Signature électronique (e-Signature) Authentifiaction avancée par certificat électronique Signature électronique de documents Signature électronique d’actions Autre Filtres d’intégrité Autres Les documents d’appel d’offres sont téléchargeables Évaluation du système C. Coûts du projet (mise en place et coûts récurrents) MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP COÛTS INTERNES 1. COÛTS DE MISE EN PLACE COÛTS FOURNISSEUR # de Jours.Homme Étude préliminaire Phase de “Design” Conception générale K$ K$ Conception détaillée Développement / Personnalisation Interfaces et intégration avec les autres systèmes Phase “Build” K$ Test de validation utilisateur, Migration des données, Go Live support K$ Formation et conduite du changement Déploiement Gestion du projet Responsable de la gestion du projet K$ K$ Nouveaux hardwares ou mises à jour du système pour supporter le projet Systèmes d’exploitation et sous-composantes associés Infrastructures K$ K$ Connectivité des réseaux Services liés aux technologies de l’information Total K$ K$ MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP 2 COÛTS DES LICENSES DEPUIS LE DÉBUT DU PROJET K$ K$ MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP COÛTS INTERNES 3. FRAIS DE FONCTIONNEMENT ANNUEL COÛTS FOURNISSEUR # de Jours.Homme Gestion technique et de fonctionnement Maintenance corrective FONCTIONNEMENT K$ K$ Maintenance évolutive (coûts d’amélioration) Autres coûts opérationnels Remarques ou commentaires TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE I 145 Annexe 4 Principes fondamentaux de la sécurité informatique Le nombre de cyberattaques n’a jamais augmenté aussi rapidement. Une étude récente de l’Institut Ponemon a révélé que les entreprises dépensent 3,86M$ par incident et qu’au cours des deux dernières années, les organisations ont perdu environ 400G$ à cause du vol et de la fraude informatiques, dans le monde entier1. Ce coût comprend à la fois les dommages directs (temps d’arrêt des infrastructures, perte de réputation...) et les dommages indirects (amendes pour les personnes concernées après une violation de données, amendes dues aux violations du RGPD...).23 PRINCIPAUX CONCEPTS À CONNAÎTRE. En ce qui concerne la sécurité informatique, il y a deux dimensions différentes à prendre en compte : (i) sécurité des données; et (ii) sécurité des applications et des infrastructures. Sécurité des données : Les différents états des données et la triade de la Central Intelligence Agency (CIA) Tout d’abord, il est important d’examiner les trois états de base des données et de comprendre les types de risques qui leur sont associés : 1. Données au repos • Les données au repos sont hébergées physiquement sur un support de stockage de données informatiques sous une forme numérique quelconque. Lorsque les données sont dans cet état, la sécurité des informations est assurée par certains composants dédiés tels que les pares-feux, les antivirus ou les mécanismes de prévention des pertes de données. Comme toute solution ou mécanisme de sécurité, ils ne sont pas efficaces à 100%. Le cryptage des données en bout de chaîne peut alors être utilisé pour surmonter ces limites.. 23. https://www.nbcnews.com/tech/security/ponemon-institute-n364871. 146 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 2. Données en transit • Les données en transit sont également connues sous le nom de données “en mouvement” ou “en vol” et font référence à un flux de données se déplaçant sur tout type de réseau. Par exemple, un courriel envoyé est un exemple de données en transit. Cependant, lorsqu’il arrive dans la boîte de réception du destinataire, il devient alors une donnée au repos. • Lorsque des données sont en transit, cela signifie qu’elles sont “en voyage” et donc plus vulnérables que l’état précédent. À chaque étape de son transfert, un hacker peut y accéder, si aucun canal sécurisé n’est utilisé. 3. Données en cours d’utilisation • Données qui sont actuellement mises à jour, traitées, effacées, consultées ou lues par un système. Dans cet état, les données peuvent être accessibles par n’importe qui si aucun contrôle d’accès strict n’est mis en place. La clé ici est de s’assurer que les mécanismes d’identification, d’authentification et d’autorisation sont correctement mis en œuvre pour éviter tout problème. En matière de sécurité des données, un autre concept fondamental est la “triade de la CIA”, également connue sous le nom des “trois grands principes de sécurité” : 24 1 Confidentialité des données : les données ne doivent pas être exposées à des personnes non autorisées. 2 Intégrité des données : elles doivent être totalement exactes et ne pas être modifiées par des personnes non autorisées. 3 Disponibilité des données : les informations ne sont accessibles qu’aux utilisateurs autorisés. La sécurité des données est une préoccupation majeure. Face au risque d’attaque, les organisations publiques ou privées ont la possibilité d’assumer cette responsabilité ou de déléguer l’hébergement des données à un développeur d’applications de confiance et de le laisser se charger de la sécurité. SÉCURITÉ DES APPLICATIONS ET TOP 10 DE L’OWASP La sécurité des applications se définit comme les mesures prises par un éditeur pour identifier, corriger et prévenir les failles de sécurité aux différentes étapes du cycle de développement du logiciel. Faire vérifier régulièrement les applications pour détecter les failles de sécurité devient de plus en plus essentiel car elles sont de plus en plus ciblées. Selon le rapport State of Software Security de Veracode, 83 % des 85 000 applications testées présentaient au moins une faille de sécurité.25 Le Top 10 de l’OWASP (Open Web Application Security Project) représente un large consensus des failles de sécurité des applications web les plus critiques, comme le montre le schéma ci-dessous. 24. 21 https://www.techopedia.com/2/27825/security/the-basic-principles-of-it-security. 25. https://www.veracode.com/state-of-software-security-report. ANNEXE 4 : PRINCIPES FONDAMENTAUX DE LA SÉCURITÉ INFORMATIQUE I 147 Schéma 48 : Top 10 des risques de sécurité des applications (dernière version du top 10 de l’OWASP publiée en 2017) L’annexe 4 fournit une description plus détaillée de chacun de ces risques. Les risques associés à ces failles sont nombreux et peuvent avoir des conséquences considérables. Si ces failles sont “non corrigées”, un hacker pourrait : (i) Facilement obtenir un accès “root” (accès administrateur) à l’infrastructure, (ii) Détourner des sessions d’utilisateurs à hauts privilèges, (iii) Modifier l’apparence de l’application web, et (iv) Modifier ou voler les données. Exigences minimales en matière de sécurité des développeurs d’applications (SaaS) ou de sécurité interne (“CUSTOM”) : Les exigences suivantes doivent être respectées pour éviter un cyber-incident ou au moins en contrôler les dommages. Il s’agit d’exigences minimales et les activités soumises à des réglementations spécifiques (comme le secret défense ou les institutions financières) peuvent être soumises à des procédures encore plus strictes. 1. TOUT D’ABORD, SENSIBILISER LES EMPLOYÉS AUX RISQUES DE SÉCURITÉ La sécurité est la mission de chacun. Même lorsque les meilleurs mécanismes de sécurité sont mis en œuvre, si les employés partagent des comptes, des mots de passe ou cliquent sur des liens suspects, c’est toute l’infrastructure qui est en danger. Il existe d’innombrables cas où l’infrastructure (sur site ou cloud) a été complètement corrompue par un logiciel malveillant pour donner suite à des attaques de phishing. Une bonne illustration de ce phénomène est la “relation d’amour/haine” des utilisateurs avec leurs mots de passe et leur tentation de les partager entre différents logins. Une enquête menée en 2020 par la société LastPass(1)a révélé que 66 % des employés stockent leurs mots de passe de manière non sécurisée ou réutilisent le même mot de passe d’une application à l’autre. ! L’homme est toujours l’élément le plus faible de la sécurité de l’information ! 148 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE 2. SÉCURISER LE DÉVELOPPEMENT DE L’APPLICATION : Si le gouvernement choisit d’opter pour une solution CUSTOM, l’un des problèmes à résoudre est de s’assurer que le cycle de développement est sécurisé. Il y a 2 moyens d’y parvenir : former l’équipe de développement aux principes de sécurité de base (basés sur le top 10 de l’OWASP mentionné précédemment) et mettre en place des logiciels de vérification de sécurité automatisés (tels que Checkmarx, Veracode, SonarQube...). En matière de sécurité des applications, il est communément admis par la communauté de la cybersécurité que choisir une application SaaS/COTS d’un éditeur de logiciels de confiance est plus sûr. Lors du processus de sélection, les gouvernements doivent vérifier que la solution SaaS/COTS aura subi de nombreux contrôles de sécurité (idéalement avant la sortie de chaque nouvelle version pour vérifier que de nouvelles vulnérabilités n’ont pas été créées). Les éditeurs de logiciels les plus avancés effectuent des tests de pénétration avec le système des 3 boîtes : boîte noire (les testeurs ne connaissent rien de l’application et tentent de s’y introduire par tous les moyens), boîte grise (un utilisateur inscrit sur l’application tente de trouver une faille pour acquérir de nouvelles autorisations), boîte blanche (le testeur a accès au code et identifie les failles de sécurité dans les différentes couches du code). La sécurité étant au cœur de leur modèle économique, les éditeurs de logiciels SaaS/COTS peuvent consacrer des ressources beaucoup plus importantes que pour un projet CUSTOM. L’avantage est évidemment que le coût de la sécurité des applications est réparti entre tous les clients. 3. ASSURER LA PROTECTION DE L’INFRASTRUCTURE : Pour un projet CUSTOM, les mesures suivantes doivent être prises : • Mise en œuvre de mécanismes de sécurité sur l’infrastructure informatique : • Les pare-feu, • Les systèmes de détection d’intrusion (IDS) et les systèmes de prévention d’intrusion (IPS) sont des systèmes de détection de réseau (IDS) conçus pour empêcher toute activité malveillante au sein d’un réseau. • Mise en place de sauvegardes de données. Les deux centres de données doivent être suffisamment éloignés l’un de l’autre pour qu’ils ne puissent pas tous deux être touchés par le même incident. Toutes ces mesures obligatoires impliquent une combinaison de matériel et de logiciels qui ont tendance à être très coûteux. Elles ne doivent pas être sous-estimées dans le processus de budgétisation. Le coût de la maintenance de ce « framework » tout au long du cycle de vie ne doit pas non plus être sous-estimé. Par exemple, le gouvernement doit effectuer des mises à jour régulières des différents équipements et doit mettre en place des tests de sauvegarde pour être sûr qu’en cas d’incident, il pourra toujours avoir accès à son application. Cela implique d’avoir une équipe de sécurité complète pour gérer son infrastructure. Pour un projet SaaS/COTS, les mesures suivantes doivent être prises : • Le gouvernement doit s’assurer que le développeur du logiciel SaaS/COTS subit un audit de sécurité régulier et se conforme aux normes de sécurité applicables. Sans ces preuves, les données sensibles risquent de ne pas être sécurisées tout au long des différentes étapes de stockage, de traitement et de transmission. • Les coûts de gestion de l’infrastructure mentionnés ci-dessus seront en effet répartis entre tous les clients de l’entreprise qui propose la solution SaaS. Sur cet aspect, l’option SaaS/ COTS (hébergée dans le cloud) est moins coûteuse. ANNEXE 4 : PRINCIPES FONDAMENTAUX DE LA SÉCURITÉ INFORMATIQUE I 149 4. ASSURER L’ÉVOLUTIVITÉ ET LA TOLÉRANCE AUX PANNES DE LA SOLUTION. Une autre exigence est de s’assurer que la solution adapte automatiquement les ressources informatiques si les demandes d’accès à celle-ci augmentent ou diminuent. Avec les solutions SaaS les plus robustes, toute l’infrastructure est construite pour répondre aux demandes à la demande et pour éviter à leurs clients d’investir dans une énorme infrastructure physique sur site. Il s’agit d’un critère d’évaluation qui ne doit pas être oublié dans le processus de sélection des éditeurs de logiciels SaaS/COTS et qui est indispensable pour tout projet CUSTOM. En outre, le gouvernement doit garantir la disponibilité de l’application en cas de défaillance d’un composant de la solution. Les gouvernements doivent analyser les garanties offertes par les éditeurs de logiciels SaaS ou COTS sur cet aspect. Dans le cas d’un projet CUSTOM, des systèmes de tolérance aux pannes RAID (Redundant Array of Inexpensive Disks) doivent être mis en œuvre pour éviter les temps d’arrêt en cas de défaillance d’un disque pour une raison quelconque. 5. UTILISEZ LA CRYPTOGRAPHIE SUR LES APPLICATIONS ET SUR LES TRANSFERTS DE DONNÉES. Pour protéger la confidentialité des données, il est important de les rendre illisibles pour les personnes non autorisées. La meilleure méthode pour y parvenir s’appelle le cryptage et consiste à convertir le texte en clair en un code secret qui dissimule l’information. Aujourd’hui, le principal algorithme cryptographique est l’Advanced Encryption Standard (AES), créé en 2001 et qui remplace le Data Encryption Standard (DES), publié en 1977. Ce mécanisme utilise des clés de cryptage permettant les processus de cryptage/décryptage. L’algorithme décrit par AES est un algorithme à clé symétrique, ce qui signifie que la même clé est utilisée pour le cryptage et le décryptage des données. Avec ce mécanisme de sécurité, même le développeur du logiciel ou l’hébergeur des données ne peut pas accéder aux données, à condition que les clés n’aient pas été partagées. L’idée est d’empêcher les personnes non autorisées d’accéder à ces clés. Il faut donc mettre en place des stratégies strictes et rigoureuses pour gérer ces clés. La mise en place d’une blockchain est souvent évoquée comme une solution ultime pour garantir l’intégrité des données. En effet, la blockchain combine le cryptage des données avec le fait que chaque “ bloc “ de données au sein du réseau Peer-to-Peer doit être modifié, ce qui rend le vol ou l’altération des données quasiment impossible d’un point de vue technique et économiquement prohibitif. Cependant, on retrouve dans la blockchain la même difficulté à sécuriser l’accès aux clés utilisées pour accéder et décrypter les données. Les usurpations d’identité sur les “ clés privées “ (ou clés de porte-monnaie) au moment de l’authentification des participants sont encore fréquentes. L’usurpation d’identité observée sur certaines blockchains monétaires suggère que, du point de vue de la sécurité, les systèmes d’authentification par clé privée ne sont pas encore totalement matures. 6. STRATÉGIE IAM (IDENTITY AND ACCESS MANAGEMENT) ET SYSTÈMES DE PROVISIONNEMENT DES COMPTES La gestion des identités et des accès (IAM) consiste à définir et à gérer les rôles et les privilèges d’accès des utilisateurs aux applications. Les utilisateurs comprennent les clients, les partenaires, les vendeurs et les employés. L’objectif central des systèmes IAM est de créer une identité numérique par individu. Une fois que cette identité numérique a été établie, elle doit être maintenue et surveillée. Les systèmes IAM fournissent aux administrateurs les outils et la technologie nécessaires pour modifier le rôle d’un utilisateur, suivre ses activités, créer des rapports sur ces activités et appliquer des politiques en permanence. Ces systèmes sont conçus pour garantir la conformité aux politiques de l’entreprise et aux réglementations gouvernementales. ”L’identité est devenue plus importante depuis que le COVID a rendu les frontières physiques non pertinentes”, déclare Andras Cser, vice-président et analyste IAM chez Forrester Research. 150 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Davantage d’entreprises se sont tournées vers les utilisateurs à distance et ont également donné aux utilisateurs extérieurs à l’organisation un accès plus large à leurs systèmes internes. “Avec l’accélération de la transformation numérique, l’identité est devenue la pierre angulaire de l’acquisition, de la gestion et de la fidélisation des clients”, ajoute-t-il. La perturbation causée par COVID a exposé les faiblesses de l’architecture IAM de nombreuses organisations et a considérablement accéléré l’évolution de l’IAM, selon le dernier rapport de Gartner intitulé 2021 Planning Guide for IAM. Quel que soit le type de mise en œuvre choisi, l’IAM est crucial pour la sécurité. Dans le cas des SaaS/COTS, les fournisseurs de cloud computing proposent le plus souvent une solution IDaaS (Identity as a Service) et peuvent la mettre en œuvre avec votre accord sur l’environnement, ajoutant ainsi une couche de sécurité supplémentaire à l’accès à vos données. 7. DISPOSER D’UN PLAN DE RÉPONSE AUX INCIDENTS DE SÉCURITÉ Une attaque de cybersécurité se produit au moins toutes les heures et les gouvernements doivent être préparés à y faire face. Une violation de données doit être gérée avec un plan approprié : réaction rapide pour qualifier le problème, mise en place d’une cellule de crise, et gestion de la communication. Les équipes qui gèrent des projets CUSTOM doivent donc régulièrement mettre à jour leur plan de sécurité et former leurs équipes sur le sujet. En cas d’incidents de sécurité sur une solution SaaS ou COTS, c’est l’équipe de l’éditeur du logiciel qui prend les devants. Leur personnel est généralement bien préparé à de tels incidents. Il est également important d’analyser les outils et processus utilisés par les fournisseurs pour la gestion de crise lors du processus de sélection. Les données et les étapes de l’e-GP doivent être sécurisées en priorité Quelles sont les données les plus à risque dans un système e-GP ? 3 catégories de données peuvent être considérées. 1 Tout d’abord, il y a les données rendues publiques conformément au principe de transparence des marchés publics. Par exemple, le nom des fournisseurs qui remportent des marchés, le montant des marchés, les spécifications ou les quantités estimées. Cette première catégorie de données n’est pas vraiment à risque : leur valeur de revente est faible, et il est relativement facile de restaurer les informations pour la continuité des opérations si elles venaient à être volées. 2 Il y a ensuite les données qui ne sont pas accessibles au public et dont la valeur de revente est faible : évaluations des fournisseurs, adresses des fournisseurs, noms des responsables des ventes, etc. Le risque lié à ces données n’est pas tant le vol que leur altération à des fins de déstabilisation. En effet, il est prévisible que ces données puissent être modifiées pour créer une perturbation majeure ou paralyser les marchés publics d’un pays : notification envoyée aux mauvais contacts, commandes envoyées aux mauvaises adresses, composition modifiée des commandes, etc. 3 La troisième catégorie est la plus sensible. Il s’agit des données non publiques relatives aux offres détaillées des fournisseurs ainsi qu’aux évaluations faites par les pouvoirs adjudicateurs lors des phases de consultation : propositions commerciales détaillées, prix unitaires donnés par les fournisseurs, fiches techniques très précises et confidentielles, évaluation des offres faites par les prescripteurs. Toutes ces données sont classées comme secret d’affaires. Si elles étaient rendues publiques, elles pourraient causer des dommages ANNEXE 4 : PRINCIPES FONDAMENTAUX DE LA SÉCURITÉ INFORMATIQUE I 151 financiers aux fournisseurs opérant dans des secteurs très concurrentiels. En outre, toutes ces données sont au cœur du processus d’approvisionnement. Si elles sont volées ou modifiées, l’ensemble du processus d’appel d’offres est compromis, ce qui entraîne des retards importants ou des annulations de procédures et, finalement, une importante destruction de valeur pour le pays. Quelles sont les étapes du processus de passation de marchés les plus menacées dans un système e-GP ? Parmi les processus couverts par les systèmes e-GP, les étapes qui concentrent le plus de risques de sécurité sont celles de l’appel d’offres en ligne, des enchères inversées et de l’évaluation/ attribution en ligne. En effet, ces processus concentrent la plupart des informations sensibles liées au secret des affaires et l’altération ou la suppression des données a sans doute les conséquences les plus importantes pour les pouvoirs adjudicateurs. Un piratage pourrait en effet entraîner d’importants retards de consultation, des annulations, des retards dans les projets gouvernementaux et des dommages sérieux pour certaines entreprises si des informations confidentielles étaient rendues publiques. Les étapes de gestion des contrats et d’achat en ligne soulèvent également des problèmes importants. Ces étapes manipulent des prix et des données confidentielles et leur piratage pourrait déstabiliser la chaîne d’approvisionnement des commandes, ralentir les projets gouvernementaux et affaiblir le réseau des fournisseurs (en raison de retards de paiement par exemple). Cependant, en cas d’attaque, il serait possible de mettre en place un système de sauvegarde : les données pourraient être facilement restaurées, et il serait possible d’utiliser des outils plus traditionnels pour passer des commandes par exemple (excel/email). En ce qui concerne les “fonctions d’appui”, il est important de garantir la sécurité du « portail fournisseurs » afin d’éviter qu’un fournisseur puisse se faire passer pour un autre, par exemple. Schéma 49 : Étapes présentant des risques de sécurité élevés dans un système e-GP AUDITS RÉGULIERS (CODE, INFRASTRUCTURE, PROCESSUS DE SÉCURITÉ) : UN MUST HAVE Phase de pré-attribution Phase de post-attribution Fonctionnalités d’appui Programmation des achats en ligne Gestion des contrats Portail fournisseurs Publication en ligne/Notification E-catalogues Gestion des fournisseurs Appel d’offres en ligne Gestion des catalogues Recherches transverses Enchères inversées Gestion des DA Suivi et rapports Evaluation et attribution en ligne Gestion des litiges Signature électronique Filtres d’intégrité Source : auteurs 152 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Comment être sûr que l’éditeur du logiciel ou que la solution CUSTOM maintient un système de sécurité fiable dans le temps ? Comment identifier les vulnérabilités le plus tôt possible et mettre en place un plan de réduction des risques ? La solution réside dans la réalisation d’audits réguliers avec l’aide d’experts spécialisés en cybersécurité. Certaines entreprises sont leaders sur ces différents audits et sont qualifiées par les autorités gouvernementales. Pour garantir la sécurité de l’application e-GP, il est essentiel que le développeur du logiciel la teste avec de multiples points de vue et avec différentes méthodologies pour s’assurer que votre application est résistante aux cyberattaques. Les différents audits à organiser sont les suivants : audit de code, audit organisationnel, audit d’architecture et de configuration et tests d’intrusion : AUDIT DU CODE Le but de cette activité est de détecter d’éventuelles failles dans le code de l’application. Pour réaliser ce type d’activité, certains outils d’analyse dynamique comme (Checkmarx, Veracode, SonarQube...) peuvent être utilisés pour une vérification préliminaire. Après ce contrôle automatisé, l’auditeur examinera manuellement le code, en vérifiant s’il contient des fonctions dépréciées ou tout autre problème de base. Cette vérification constitue la première barrière de sécurité.. AUDIT ORGANISATIONNEL L’éditeur du logiciel ou les équipes internes mettent-ils régulièrement à jour les processus de sécurité ? La seule façon de vérifier cette dimension est de réaliser un audit organisationnel. Il consiste à identifier les faiblesses liées au processus de gestion de la sécurité. De nombreux sujets sont vérifiés lors de cet audit, notamment la politique de sécurité, les ressources humaines, la gestion des actifs, l’intégration de la sécurité dans le cycle de vie des systèmes en nuage et la sécurité du réseau. AUDIT DE L’ARCHITECTURE ET DE LA CONFIGURATION Cet audit analyse précisément l’architecture déployée dans votre solution cloud ou vos systèmes sur site pour vérifier si le durcissement de chaque composant est à jour et si tous les paramètres de sécurité sont appliqués. TESTS D’INTRUSION Est-il possible pour des personnes non autorisées d’obtenir un accès au système e-GP ? Est-il possible pour ce type de personnes d’exploiter certaines vulnérabilités et d’obtenir des privilèges “root” ? La seule façon de s’assurer qu’elles ne le peuvent pas est de procéder à un test d’intrusion pour confirmer que les défenses tiennent le coup comme prévu. Test d’intrusion externe Test d’intrusion interne ANNEXE 4 : PRINCIPES FONDAMENTAUX DE LA SÉCURITÉ INFORMATIQUE I 153 Plusieurs modes peuvent être utilisés lors de cette activité comme le mode boite noire (tests d’intrusion sans aucune connaissance de la cible), le mode boite grise (tests d’intrusion avec un accès à un compte non privilégié pour vérifier la possibilité d’avoir une escalade de privilèges sur le système) et le mode boite blanche (tests d’intrusion avec une connaissance complète de la cible et avec un accès au code source). Entrée Entrée Sortie Sortie Test en boite noire Test en boite blanche 154 I TYPES D’IMPLÉMENTATION DES SYSTÈMES EN LIGNE DE GESTION DES MARCHÉS PUBLICS : OPTIONS POUR L’AFRIQUE Annexe 5 Les 10 principaux risques liés à la sécurité des applications Web Le Top 10 de l’OWASP est un document de sensibilisation standard pour les développeurs informatiques en charge de la sécurité des applications web. Il représente un consensus sur les risques de sécurité les plus critiques pour les applications web.26 1 A1:2017-Injection : Les failles d’injection, telles que l’injection SQL, NoSQL, OS et LDAP, se produisent lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d’une commande ou d’une requête. Les données hostiles du hacker peuvent inciter l’interpréteur à exécuter des commandes non souhaitées ou à accéder à des données sans autorisation appropriée.27 2 A2:2017 - Authentification brisée : Les fonctions d’application liées à l’authentification et à la gestion des sessions sont souvent mises en œuvre de manière incorrecte, ce qui permet aux hackers de compromettre les mots de passe, les clés ou les jetons de session, ou d’exploiter d’autres défauts de mise en œuvre pour prendre l’identité d’autres utilisateurs de manière temporaire ou permanente. 3 A3:2017-Exposition de données sensibles : de nombreuses applications web et API ne protègent pas correctement les données sensibles, telles que les données financières ou les donnée de santé. Les hackers peuvent voler ou modifier ces données faiblement protégées pour réaliser des fraudes à la carte de crédit, des vols d’identité ou d’autres crimes. 4 A4:2017-XML Entités externes (XXE) : De nombreux processeurs XML anciens ou mal configurés évaluent les références aux entités externes dans les documents XML. Les entités externes peuvent être utilisées pour divulguer des fichiers internes à l’aide du gestionnaire URI de fichiers, des partages de fichiers internes, l’analyse de ports internes, l’exécution de code à distance et des attaques par déni de service. 5 A5:2017-Contrôle d’accès défaillant : Les restrictions sur ce que les utilisateurs authentifiés sont autorisés à faire ne sont souvent pas correctement appliquées. Les hackers peuvent exploiter ces failles pour accéder à des fonctionnalités et/ou des données non autorisées, telles que l’accès aux comptes d’autres utilisateurs, la visualisation de fichiers sensibles, la modification des données d’autres utilisateurs, la modification des droits d’accès, etc. 6 A6:2017 - Mauvaise configuration de la sécurité : La mauvaise configuration de la sécurité est le problème le plus fréquemment rencontré. Cela résulte généralement de configurations par défaut non sécurisées, de configurations incomplètes ou ad hoc, de stockage en open cloud, d’en-têtes HTTP mal configurés et de messages d’erreur verbeux contenant des informations sensibles. Non seulement tous les systèmes d’exploitation, les frameworks, les bibliothèques et les applications doivent être configurés de manière sécurisée, mais ils doivent également être corrigés/mis à niveau en temps utile. 26. https://owasp.org/www-project-top-ten/. 27. https://analyse-innovation-solution.fr/publication/fr/php/objet-pdo-et-securite-mysql. ANNEXE 5 : LES 10 PRINCIPAUX RISQUES LIÉS À LA SÉCURITÉ DES APPLICATIONS WEB I 155 7 A7:2017-Cross-Site Scripting XSS : Les failles XSS se produisent lorsqu’une application inclut des données non fiables dans une nouvelle page Web sans validation ou échappement approprié ou met à jour une page Web existante avec des données fournies par l’utilisateur en utilisant une API de navigateur qui peut créer du HTML ou du JavaScript. XSS permet aux hackers d’exécuter des scripts dans le navigateur de la victime, ce qui peut détourner les sessions de l’utilisateur, défigurer les sites web ou rediriger l’utilisateur vers des sites malveillants. 8 A8:2017-Désérialisation non sécurisée : La désérialisation non sécurisée conduit souvent à l’exécution de code à distance. Même si les défauts de désérialisation n’entraînent pas l’exécution de code à distance, ils peuvent être utilisés pour réaliser des attaques, notamment des attaques par rejeu, des attaques par injection et des attaques par élévation de privilèges. 9 A9:2017-Utilisation de composants présentant des vulnérabilités connues : Les composants, tels que les bibliothèques, les frameworks et autres modules logiciels, s’exécutent avec les mêmes privilèges que l’application. Si un composant vulnérable est exploité, une telle attaque peut faciliter de graves pertes de données ou la prise de contrôle du serveur. Les applications et les API utilisant des composants présentant des vulnérabilités connues peuvent miner les défenses de l’application et permettre diverses attaques et impacts. 10 A10:2017-Consignation et surveillance insuffisantes : Une journalisation et une surveillance insuffisantes, associées à une intégration manquante ou inefficace avec la réponse aux incidents, permettent aux hackers d’attaquer davantage les systèmes, de maintenir la persistance, de pivoter vers plus de systèmes et de falsifier, extraire ou détruire les données. La plupart des études sur les violations montrent que le temps de détection d’une violation est supérieur à 200 jours, généralement détecté par des parties externes plutôt que par des processus ou une surveillance internes. Types d’implémentation des systèmes en ligne de gestion des marchés publics : options pour l’Afrique ÉQUIPE PROJET : Blandine Wu Chebili - World Bank Group Hunt La Cascia - World Bank Group François Collineau - CKS Consulting Arnaud Salomon - CKS Consulting Baptiste Calvet - CKS Consulting Yoann Moreau - SQUAD