METHODE Réussir Sa Négociation de Contrat SIG CLOUD

Système Informatisé de Gestion en Cloud
Eléments-clés pour réussir sa négociation contractuelle et financière
Ce modèle de document réalisé par ADA, dans le cadre du programme Digital Finance Initiative, est disponible
librement sur le site www.ada-microfinance.org
Introduction
• Ce guide a été créé à l’attention des institutions de microfinance (IMF) et Systèmes Financiers
Décentralisés (SFD) engagés dans une démarche de changement de leur Système Intégré de Gestion (SIG).
Il vise à mettre en avant quelques éléments clés dans la négociation des contrats avec un fournisseur, afin
d’assurer un bon déroulement de la mise en œuvre et de l’utilisation future de la solution.
• La phase de pré-vente est la phase clé car tant que rien n’est signé avec le fournisseur, tout peut être
négocié et le fournisseur sera plus enclin à discuter. Une fois le contrat signé (et donc gagné) par le
fournisseur, il sera moins enclin à offrir gracieusement de nouvelles prestations, mais au contraire à
essayer de vendre des modules fonctionnels et des prestations de service supplémentaire.
• La revue de cet ensemble de points ne permet pas de s'affranchir d'une revue juridique des contrats. Elle
permet de s'assurer d'une maîtrise des risques sur des points clés d'un achat de logiciel et qui peuvent
constituer -en fonction du contexte- des leviers de négociations utiles. Il est recommandé aux institutions
de microfinance de faire relire tout contrat avec leurs juristes avant signature.
Table des matières
• Expression des besoins

• Analyse de la couverture fonctionnelle
• Développements spécifiques
• Contrat de mise en œuvre du SIG
• Négociation du contrat: Licence logicielle
• Négociation du contrat: Maintenance logicielle
• Négociation du contrat: Support utilisateur
• Négociation du contrat: Hébergement
• Négociation financière du contrat
• Négociation du calendrier de paiement
• Ce qu’il faut retenir
Expression des besoins
La négociation contractuelle est la dernière étape de sélection d’un logiciel, et ne peut être réussie que si les étapes
précédentes ont été correctement effectuées:
1. Une analyse fine des besoins de l’utilisateur:
Cette première étape du processus de changement de SIG donne lieu à l’élaboration des cahiers des charges de
besoins (fonctionnels et techniques) de l’institution. Le plus grand soin doit être apporté à ce cahier des charges, qui
est inclus en annexe du contrat d’implémentation, et contractualise ainsi ce qui sera délivré par le fournisseur.
L’enjeu pour l’institution est d’arriver à mettre en valeur les éléments essentiels pour les processus fondamentaux de
l’institution, (tels que les produits de crédit, d’épargne, et la comptabilité des opérations), au lieu d’essayer de
détailler toutes les fonctionnalités, et également de se projeter de manière réaliste dans ses besoins futurs.
A titre d’exemple, une IMF ou un SFD en zone UEMOA pourra inclure dans ses besoins futurs des solutions digitales
de type application mobile pour ses agents de terrain et pour ses clients, mais n’a pas d’intérêt à demander l’édition
de moyens de paiements de type chèques, virements bancaires, ou cartes de crédit, si elle ne possède pas de une
licence bancaire (ou équivalent selon la réglementation en vigueur)
D’autre part, un biais généralement rencontré par les SFD est d’essayer d’identifier une solution « tout-en-1 » ayant
la plus vaste couverture fonctionnelle, au détriment de la qualité de chaque fonction. Mieux vaut un SIG robuste et
flexible sur les dimensions opérationnelles et financières, couplé à des logiciels tiers (paie, immobilisations, stocks.,
BI…) qu’un logiciel cherchant à couvrir toutes ces fonctions, sans pouvoir égaler chacune de ces solutions
spécialisées.
2. Une étude de marché
Afin de faciliter la projection dans ses besoins futurs et enrichir son cahier des charges, l’institution peut
réaliser une étude de marché. Celle-ci prend en compte:
• Les obligations réglementaires du pays ou de la zone dans laquelle elle opère, le SIG sélectionné
devant se conformer à ces obligations
• Les fonctionnalités qu’utilisent les concurrents directs de l’institution (autres institutions de
microfinance)
• Les meilleures pratiques du marché et des industries connexes, comme par exemple les opérateurs
mobiles, les émetteurs de monnaie électronique, les services de transferts d’argent…
Afin de réaliser cette étude de marché, l’institution peut s’appuyer sur la littérature existante (notamment les
sites du CGAP-Findev, du GSMA…), sur des consultants, sur ses partenaires financiers réguliers, et discuter
avec d’autres IMF et SFD.
Le guide technique des systèmes d’information du CGAP fournit un cadre méthodologique de qualité pour
réussir la sélection du SIG.
3. Un appel d’offre
L’appel d’offre permet la mise en concurrence de différents fournisseurs de solutions.

Il est intéressant de ne pas limiter la comparaison des offres aux fonctionnalités du SIG, mais également aux
services annexes proposés, au plan d’implémentation, au mécanisme de pricing, à l’accompagnement et la
formation des utilisateurs, aux méthodologies utilisées, aux capacités techniques du fournisseur, à la langue
principale du fournisseur, à ses éventuels sous-traitants… l’étude des atouts et faiblesses des différents
fournisseurs sera un élément clé pour la négociation finale.
A titre d’exemple, un fournisseur peut décider de prendre à sa charge les jours d’implémentation
supplémentaires en cas de dépassement du projet, un autre peut proposer d’offrir la première année de
maintenance, un autre possède un représentant local actif et techniquement compétent dans le pays où
l’institution opère… ces arguments une fois identifiés peuvent être mis en avant dans la phase de
négociation.
Exemple de matrice d’analyse d’un SIG
• Forces
Clients, crédit,
épargne
• Couverture fonctionnelle adaptée Relation long- 10 Comptabilité,
9
• Expérience du fournisseur pour les IMF terme 8 immos, paie,
fournisseur 7 GRH
• Représentant local sérieux, 17 IMF clientes 6
dans le pays 5
Qualité de 4 Reportings &
• Expérience de Migration depuis l’ancienne 3
solution l'implémentation 2
Reglementaire
1
0
• Faiblesses Robustesse Mobilité: agents

• Faible expérience Cloud fournisseur de terrain
• Applications mobiles débutantes
• Ergonomie et qualité logicielle Robustesse du
Mobilité: clients
SaaS
Robustesse et
ergonomie
logiciel
Exemple de comparaison des SIG
Fournisseur #1 Fournisseur #2 Fournisseur #3 Fournisseur #4 Fournisseur #5 Fournisseur #6
30%* 63%* 54%* 72%* 78%* 16%*
* Cette pondération reflète une première compréhension des fournisseurs et solutions à l’issue de la phase de
dépouillement des offres Cette compréhension devra être affinée dans la phase de démonstration des solutions
Exemple de comparatif financier des SIG
Coût total de possession sur 5 ans, en M XOF
500.000
400.000
300.000
200.000
100.000
Fournisseur #1 Fournisseur #2 Fournisseur #3 Fournisseur #4 Fournisseur #5

160 000 MXOF 70 000 MXOF 410 000 MXOF 135 000 MXOF 100 000 MXOF
Investissement initial
Implémentation 10 000 10 000 70 000 20 000 5 000
Licence 70 000 30 000 120 000 30 000 35 000
Coûts d'exploitation 5 ans
Maintenance 80 000 25 000 120 000 85 000 30 000
Hébergement
Cloud 0 5 000 100 000 0 30 000
Analyse de la couverture fonctionnelle
La couverture fonctionnelle est la liste de l’ensemble des fonctionnalités (ou actions) que devra pouvoir effectuer le SIG. C’est un des
éléments-clés du contrat, car toutes les fonctionnalités non-présentes et nécessaires à l’institution devront faire l’objet de développements
spécifiques.
La réponse à l’appel d’offre donne un premier aperçu de la couverture fonctionnelle d’une solution, cependant, certains fournisseurs pour
passer les premières étapes de sélection n’hésitent pas à indiquer de manière enthousiaste dans leur réponse des fonctionnalités qui ne
sont pas toujours matures.
Afin de valider la bonne couverture fonctionnelle, il est recommandé de négocier avec les fournisseurs:
• Une démonstration approfondie (de 4h à 8h) sur la base de scénarios d’essai écrits par l’institution, idéalement avec des jeux de
données du client
• Un accès à une base de test en Cloud pour une durée de 10 jours, permettant de tester en profondeur les scénarios. Cette étape étant
chronophage, ne tester au maximum que deux solution (en accentuant les tests sur la plus pertinente). Les guides utilisateurs et bases
documentaires du fournisseur sont des alliés précieux pour évaluer la couverture fonctionnelle réelle de la solution.
• Des discussions avec des clients utilisant les fonctions clés (comptabilité dans le même référentiel comptable, solutions mobiles pour le
même type d’opérations : par exemple si l’institution privilégie le crédit de groupe, la collecte d’épargne régulière…) afin de valider la
robustesse des processus-clés.
Une fois la couverture fonctionnelle EFFECTIVE bien déterminée, l’institution peut lister les fonctions non-présentes et leur degré de
criticité (voir la matrice en exemple ci-après). Ce travail en profondeur d’analyse est fréquemment effectué en première phase
d’implémentation, mais l’anticiper dans la phase précontractuelle permet de mieux cadrer le projet et en limiter les risques.
Analyse de la couverture fonctionnelle
Il est couramment admis qu’un bon SIG peut couvrir environ 80% des besoins de l’institution. Pour les 20% restants,
lorsque cela est possible, il est fortement recommandé d’adapter les processus de l’institution plutôt que de
demander des développements spécifiques. En effet ceux-ci présentent un nombre de risques élevés:
• Risque de périmètre fonctionnel: à moins d’avoir une expertise dédiée au sein de l’institution, il n’est pas
toujours évident de bien spécifier fonctionnellement et techniquement son besoin, notamment si celui-ci
n’était pas déjà bien défini et couvert dans un ancien système.
• Les impacts d’une nouvelle fonctionnalité sur les fonctionnalités existantes ne sont pas toujours bien
identifiées en amont, et à moins d’avoir une expertise interne en test et qualité logicielle, l’institution en
tant que premier client risque d’avoir une fonctionnalité qui ne satisfait pas le besoin à la première itération
et devra travailler en cycles d’amélioration avec le fournisseur jusqu’à stabiliser le système (ceci pouvant
prendre plusieurs mois)
• De nouvelles fonctions nécessitent un (ou plusieurs) cycle de développement, impliquant des délais à
l’implémentation. Or plus l’implémentation dure, plus son impact sur la productivité de l’institution (et
par conséquent son résultat financier) est important car celle-ci mobilise le temps des ressources clés de
l’institution, qui ne sont pas disponibles à d’autres tâches génératrices de revenus immédiats (acquisition
client, croissance du portefeuille, recouvrement…)
• Le fournisseur facture des coûts de développement supplémentaire aux nouvelles fonctions. Le coût est
défini en amont, mais si la fonctionnalité a été mal définie ou ses impacts mal analysés, le fournisseur
refacturera ces surcoûts.
Exemple: développements spécifiques
Les développements spécifiques identifiés peuvent-être classés et étudiés selon plusieurs critères (criticité, complexité,
risque, surcoût…) à l’aide d’une matrice comme dans l’exemple ci-dessous:
Fonctionnalité Criticité Complexité Risque Surcoût Décision
#1: Valider le numéro Moyenne: Forte: nécessite la mise en Faible: Risque de Fort: si aucune Non Fonction probablement
de téléphone du permettrait de place d’un module OTP retard du projet mais intégration de déjà dans la roadmap du
client à l’enrôlement réduire la fraude chez le fournisseur +la la fonction pourrait plateforme SMS est fournisseur. Demander à en
par l’envoi d’un code (clients fictifs) mais contractualisation et être contournée si elle déjà en place. bénéficier quand celle-ci sera
SMS (également implique des coûts l’intégration avec une ne fonctionne pas dès disponible, sans surcoût
appelé One Time d’envoi de SMS. plateforme de SMS. l’implémentation
Password - OTP)
#2 Editer Critique: Ces états Moyenne: l’édition d’états Critique: la non- Faible: cette Oui: Demander à en
automatiquement la doivent être implique la lecture production de ces demande étant bénéficier dans le cadre de
liasse règlementaire produits d’information dans la base rapports entraine un standard pour l’implémentation sans
liée au nouveau périodiquement et de données, mais pas de risque règlementaire l’ensemble des SFD surcoût, car le fournisseur
référentiel comptable leur élaboration est modification des de l’institution de la zone, elle est l’avait indiqué comme
de la BCEAO chronophage et fonctionnalités existantes probablement déjà « fonctionnel » dans la
source d’erreurs dans la roadmap du réponse à l’appel d’offre
fournisseur.
Note: en cas de développements spécifiques payés par le client, l’éditeur informatique peut vous concéder un droit d’usage dans le cadre d’une licence
ou vous transmettre les droits de propriété industrielle par cession de droits.
Ces modalités sont à négocier et à inclure dans le contrat.
Contrat de mise en œuvre du SIG
• La mise en œuvre du SIG (également appelée « implémentation ») fait l’objet d’un contrat spécifique de prestation
informatique.
Ce contrat doit spécifier à minima:
• Le périmètre de l’implémentation: l’installation et le paramétrage du logiciel, la reprise des données, la migration de
l’infrastructure, la mise en place de la mobilité…
• Les rôles et responsabilités de chacun: institution, fournisseur, consultant tiers… Il est recommandé d’utiliser une
matrice « RACI » afin de formaliser ces responsabilités (voir exemple page suivante)
• Le plan projet, avec un découpage par activité, la définition des étapes-clés et des livrables associés, et le calendrier de
paiement du prestataire aligné sur ces livrables.
• S’il y a nécessité d’un ou plusieurs pilotes (sur une agence, sur un nombre d’agents de crédit…) ces points sont
également à mentionner dans le contrat ou dans ses annexes.
Note: il est fortement recommandé d’annexer au contrat d’implémentation:

• Le cahier des charges de besoins, ou à défaut la matrice de spécifications fonctionnelles éditée dans le cadre de l’appel
d’offre. Indiquer que contractuellement le prestataire s’engage à implémenter, former et supporter le client sur
l’ensemble des fonctionnalités qu’il a indiqué comme « disponibles » dans son cahier des charges
• Les spécifications fonctionnelles des développements spécifiques (si nécessaires) avec le coût de développement
associé
• Le calendrier d’implémentation précisant les dates de réception des livrables associés
Exemple de matrice RACI
La matrice RACI définit les rôles et responsabilités sur un projet. Cet acronyme RACI signifie :
R: Réalise: C’est la Ressource qui Réalise l’activité. Il peut y avoir plusieurs R.
A: Autorité: A l’autorité pour approuver le travail de R. Il n’y a qu’un seul A.
C: Consulté: Est consulté par R. La communication entre R et C est bidirectionnelle. Il peut y avoir plusieurs C.
I: Informé: Est uniquement informé des travaux de R. Il peut y avoir plusieurs I.
Directeur IT
Fournisseur
Opérations
projet SFD
Directeur
Directeur
Directeur
Financier
Chef de
SFD
SIG
Activité du projet
Plan de migration du SIG R A C C C R
Infrastructure des agences et points de service A C I R C
Migration des données A, R I I C R R
Test du SIG A, R I R R R R
Mécanismes de tarification de la mise en œuvre
Il existe 2 grands mécanismes de facturation des prestations informatiques, chacun ayant ses avantages et ses
inconvénients:
• Dans un contrat au forfait: la rémunération est fixée à l’avance, en fonction de la réalisation de l’objectif
attendu. Cela implique que l’objectif aura été défini dans un cahier des charges et que la manière d’en
constater l’aboutissement l’aura été aussi (recettes). Le prestataire a une obligation de résultats (et y alloue
les moyens nécessaires). Les changements éventuels en cours de projet sont généralement plus difficiles à
obtenir du prestataire
• Dans un contrat en régie: (ou au réel) la rémunération est proportionnelle aux moyens humains (nombre de
jours/hommes) et matériels (transport, per-diem…) mis à la disposition du client, là aussi selon les modalités
du contrat. Le prestataire a principalement une obligation de moyens (et de résultats). Il est
généralement plus ouvert aux changements de projet (qu’il facture au réel) la contrepartie étant que le prix
initial risque d’augmenter au fil du temps et des modifications.
Une situation généralement confortable pour un projet d’implémentation est d’arriver à négocier avec le fournisseur
un contrat au forfait avec un prix fixe et une obligation de résultats, et d’y inclure une clause où il précise les moyens
minimums qu’il s’engage à mettre en œuvre pour y parvenir (par exemple le nombre de jours sur site pour chaque
ressource, pour chaque phase de l’implémentation)
Exemple: planning de mise en œuvre du SIG
Note: ce modèle de planning peut être retrouvé sur l’outil de planification Smartsheet via ce lien
Négociation du contrat: licence logicielle
Le contrat de licence logicielle est un des éléments à regarder avec attention lors de la phase de négociation. Les articles à
étudier précisément sont:
1. La portée du contrat de licence. Celle-ci peut être indexée sur un ou plusieurs indicateurs comme:
• Le nombre d’utilisateurs total, ou de postes de travail, ou d’agences… Idéalement une licence unique permettant un
nombre illimité permet à l’institution d’envisager sereinement sa croissance. Il faut notamment prendre en compte le
cas du client « self-service » où l’ensemble des clients de l’institution peuvent accéder
=> Note: Dans certains cas il pourrait être pertinent pour l’institution cliente de stipuler une variation de la redevance
en fonction du nombre d’utilisateurs du logiciel. Cette variation doit alors pouvoir être contractuellement renégociable
périodiquement à la hausse ou à la baisse
• Le volume de données traités (clients, crédits, comptes…): Idéalement une licence unique permettant un nombre
illimité permet à l’institution d’envisager sereinement sa croissance
2. La durée du droit d’utilisation: idéalement illimité
3. La transférabilité des licences, dans le cas où le client souhaite migrer de serveur, ou repasser d’une version « Cloud » à
une version hébergée localement (« On-Premise »)
4. Le prix du contrat de licence. Dans le cadre d’un contrat « Licence + Maintenance », la licence est due une seule fois et
la maintenance annuelle est généralement indexée au prix de licence initial (il peut également s’agir d’un prix fixe dans
certains cas)
Négociation du contrat: licence logicielle
5. Les modules additionnels et développements spécifiques: vérifier qui détient les droits de propriété des
développements effectués et les licences logicielle éventuelles qui s’appliquent.
6. Le client veille à conserver la propriété de l’ensemble des données traitées via la solution logicielle, et
pourra extraire ses données facilement et gratuitement lorsque il en aura besoin
7. Le client peut s’assurer de la pérennité de la solution logicielle choisie en négociant une clause d’accès au
code source du logiciel (dans le cas où le fournisseur ferait faillite par exemple)
8. La clause de recette et le calendrier de paiement de la licence:
• Après une période de tests, l’institution peut prononcer la recette provisoire si le logiciel remplit les
exigences de son cahier des charges. Il s’agit généralement de la date de mise en production
• La recette définitive a lieu après une vérification du service rendu. La vérification permet de constater le
bon fonctionnement du logiciel. Le prononcé de la recette définitive marque le point de départ des
garanties (généralement quelques mois après la mise en production
• Il est recommandé de payer la licence en tranches, notamment le solde une fois la recette définitive
effectuée (voir la rubrique « calendrier de paiement»)
Négociation du contrat: maintenance logicielle
• La maintenance logicielle comporte 2 composantes:

• La maintenance corrective vise à résoudre les erreurs de logiciels (bugs)
• La maintenance évolutive vise à mettre à jour périodiquement le logiciel permettant au client de
bénéficier de fonctionnalités améliorées
Le détail de l’application des conditions de maintenance est généralement spécifié dans une matrice de
conditions de service (ou Service Level Agreement – SLA). Ce contrat est habituellement couplé avec celui de
support utilisateur, et peut être couplé au contrat d’hébergement dans le cas de solutions en SaaS ou en
Cloud.
La maintenance est généralement due à la date de mise en production du logiciel - le calendrier de
paiement de la maintenance doit être aligné aux calendrier d’implémentation et de paiement de la licence
(voir la rubrique « calendrier de paiement»)
Les points d’attention sur le volet de maintenance corrective sont les suivants:
• Le fournisseur ne peut pas rompre unilatéralement la maintenance
• Le fournisseur ne peut pas modifier unilatéralement les conditions du contrat de maintenance
• Le fournisseur ne peut pas modifier unilatéralement le tarif du contrat de maintenance
• Vérifier ce que le fournisseur s’engage à réparer (en cas de bugs) ou pas
• S’assurer de l’effectivité de l’assistance technique dont elle pourrait bénéficier au titre du contrat de licence.
• Vérifier les délais de prise en charge des éventuels erreurs (dans la matrice de conditions de services)
• Vérifier les coûts additionnels en cas de déplacement du fournisseur chez le client (que ce soit pour les
maintenance correctives et évolutives)
Les fournisseurs les plus sérieux proposent un outil de gestion de tickets en ligne pour suivre les demandes de
maintenance corrective et s’assurer que les conditions de services sont proposées. Dans le cas où votre fournisseur
ne le propose pas, vous pouvez lui proposer de mettre en place un outil spécifiquement pour ce projet (freshdesk
propose par exemple une version gratuite et en français suffisante pour du suivi de tickets), ou à défaut partager
un fichier en ligne de suivi des incidents (par exemple Google Spreadsheet)
• Les points d’attention sur le volet de maintenance évolutive sont les suivants:
• La fréquence de mise à jour est à définir (idéalement annuelle ou bi-annuelle selon la complexité du
logiciel, sa capacité à évoluer rapidement, et la maturité des équipes informatiques du client à
absorber les mises à jour
• Les modalités techniques de mises à jour: peut-elle se faire à distance ou nécessite-t-elle un
déplacement physique du fournisseur ou d’un de ses partenaires ? Dans ce cas quel est le coût
additionnel de ces prestations ?
• La possibilité pour le client de tester les nouvelles versions sur une environnement dédié (de
type bac à sable, ou sandbox) avec ses données réelles
• La documentation de chaque mise à jour, avec
• La liste des modifications, qu’il s’agisse de corrections de bugs ou de nouvelles fonctions
(release note)
• Le guide utilisateur mis à jour avec si nécessaire les outils de formations pour les utilisateurs du
logiciels
Négociation du contrat: support utilisateurs
• Les conditions d’application du support utilisateur sont généralement régies par 2 documents, qui
idéalement sont annexés au contrat:
• Les conditions de services (ou SLA) - communes à la maintenance corrective, permettent de
qualifier le niveau de gravité d’une erreur (selon la criticité de la fonctionnalité affectée et le nombre
d’utilisateurs affectés), et indiquent les délais maximum de prise en charge de l’incident par le
support et de résolution de cet incident et de rétablissement du service, en fonction de cette gravité
• La matrice d’escalade du support indique les niveaux de hiérarchie auxquels contacter le
prestataire et ses partenaires dans le cas où un incident reste non-résolu
Dans cette matrice de condition de services, il est essentiel pour le client de personnaliser et définir
précisément les niveaux de gravité en fonction de son activité. A titre d’exemple,
- Un bug empêchant les opérations d’épargne pourra être pénalisant pour certains clients, et non pour
d’autres qui se feraient que du crédit.
- Un bug touchant les applications web et mobiles des client aura un impact faible pour une institution
réalisant la majorité de son activité via ses agents, mais sera critique pour une institution fonctionnant
exclusivement en « client self-service »
Négociation du contrat: hébergement logiciel
De plus en plus de fournisseurs proposent leurs logiciels en tant que service (Software as a Service - SaaS) ou hébergé
dans un datacenter (le Cloud).
Cette approche est généralement très bénéfique pour IMF et SFD, car elle permet au département informatique de se
décharger d’un grand nombre de tâches techniquement complexes, à risque, et à faible valeur ajoutée, pour se
concentrer sur d’autres activités (comme un meilleur support utilisateur)
Le sujet du Cloud étant assez complexe, et relativement récent chez les fournisseurs de SIG, dont certains
n’appréhendent pas encore tous les enjeux à ce jour, il est important de comprendre quelques concepts-clés afin de ne
pas faire d’erreur dans le contrat d’implémentation
- Le niveau de service proposé par le vendeur: généralement catégorisé en 3 niveaux: Infrastructure as a Service (IaaS),
Platform as a Service (PaaS) et Software as a Service (SaaS) comme présenté dans le tableau de la page suivante. Le
plus approprié est généralement le SaaS, qui sera développé dans la suite de ce document.
- Le prestataire (ou hébergeur) sur lequel s’appuie le fournisseur de SIG. Sa robustesse, et sa renommée sont
généralement des gages de qualité du service. Trois « géants du web » se partagent la majorité du marché de
l’infrastructure Cloud et sont généralement signe de confiance: Amazon Web Services (ou AWS), Google Cloud, et
Microsoft Azure.
Note: ces fournisseurs d’infrastructure offrent une garantie de qualité dans la mesure où le prestataire de SIG maîtrise
ces offres. Ne pas hésiter à vérifier les certifications AWS, Google ou Azure détenues par les salariés du fournisseur de
SIG.
Comparatif des hébergements logiciels
« On Premise » Infrastructure as a Platform Software as a
Service as a Service Service
Applications Applications Applications Applications
Données Données Données Données
Runtime Runtime Runtime Runtime
Intégrations Intégrations Intégrations Intégrations
Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation
Virtualisation Virtualisation Virtualisation Virtualisation

Serveurs Serveurs Serveurs Serveurs
Stockage Stockage Stockage Stockage
Réseau Réseau Réseau Réseau
Géré par le client Géré par le fournisseur Ce modèle de document réalisé par ADA, dans le cadre du programme Digital
Finance Initiative, est disponible librement sur le site www.ada-microfinance.org
Négociation du contrat: hébergement logiciel
• Les points clés du contrat d’hébergement SaaS:
• Négocier un plafonnement des prix au renouvellement du contrat (généralement annuel) pour s’assurer que les coûts
des contrats de SaaS restent dans le budget. (habituellement, la hausse ne dépasse pas 3 %)
• Identifier et négocier de manière proactive les éventuels frais « cachés » qui peuvent s’appliquer au contrat de
SaaS (coût de stockage des données, appels d’API)
• S’assurer de la mise à disposition d’un ou plusieurs espaces de tests (Bac à sable)
• Passer soigneusement en revue les modalités relatives à la sécurité et à la confidentialité des données pour s’assurer de
la conformité avec les impératifs de l’institution. Exiger un niveau minimum de sécurité (minimum SOC2 et ISO 27001 et
27002, idéalement une certification PCI DSS)
• S’assurer que le fournisseur de SaaS assume la responsabilité de ses sous-traitants
• Inclure des niveaux de service clés (SLA) et des recours appropriés, tels que la définition du temps d’arrêt, les temps de
réponse aux incidents, les temps de résolution des incidents, les objectifs de reprise après sinistre.
• Négocier un droit de résilier le contrat à tout moment dans le futur si les niveaux de service convenus n’étaient pas
respectés pendant trois mois quelconques sur une période continue de 12 mois
• Négocier une réplication locale quotidienne des données afin de se conformer à la règlementation locale
• S’assurer qu’il sera possible d’extraire et de réutiliser les données de l’institution facilement ou gratuitement lorsque elle
en aura besoin
Négociation financière du contrat
• L’avantage de l’appel d’offre est de permettre la mise en concurrence de plusieurs fournisseurs. Essayez de garder le plus
longtemps possible une négociation avec 2 fournisseurs (ou la possibilité de vous retourner vers votre second choix
technique) pour garder des atouts durant la négociation (ne pas indiquer à un fournisseur que vous êtes en négociation
exclusive avec lui)
• Trop souvent, la négociation financière se fait sur une vision court-terme. Afin d’avoir une meilleure visibilité il est intéressant
de consolider l’ensembles des coûts sur une période donnée, avec par exemple 2 scenarios: le coût total de possession à 5
ans et à 10 ans
• En fonction de ce tableau, il est alors possible de négocier du montant le plus important au moins significatif. Généralement
dans le cas d’un contrat de licence + maintenance dans l’ordre suivant:
• Le coût de licence logicielle (module par module)
• La possibilité de fixer le prix d’un module mais de l’activer plus tard, en fonction des besoins
• Le taux (%) de maintenance annuelle
• Le modèle de partage de commissions (montant fixe ou pourcentage de la commission, dans le cas de certains services
(comme l’intégration en API avec un prestataire de scoring ou de M-Wallet)
• Le coût de l’hébergement ou du service SaaS
• La possibilité d’offrir la maintenance la première année (période de garantie offerte)
• Le coût de la prestation d’implémentation
• La prise en charge directement par le client des frais sur site (hôtel, restauration, perdiem, transport…)
Les conditions et délais de rétractation doivent également être négociés et contractualisés
Ce modèle de document réalisé par ADA, dans le cadre du programme Digital Finance Initiative, est disponible librement sur le site www.ada-microfinance.org
Négociation du calendrier de paiement
Le client peut se retrouver avec 3, 4 ou 5 contrats pour les différents aspects du projet (licence, maintenance,
support, hébergement, implémentation, développements spécifiques) et il est recommandé, dans la mesure
du possible d’aligner l’ensemble des calendriers de paiement de ces contrats.
La logique est que le client paie par tranche les contrats en fonction des services rendus et livrés.
Le fournisseur, lui, aura tendance à vouloir encaisser les montants le plus tôt possible indépendamment des
phases (et des risques) du projet.
Les grandes lignes ci-dessous permettent d’établir le calendrier de paiement:
• Paiement de la phase d’implémentation par tranches (mensuelles) en lien avec les livrables validés du plan
d’implémentation
• Paiement de la licence à l’issue de la phase d’implémentation, 50% à la recette provisoire (mise en
production), 50% à la recette définitive (au bout de quelques mois d’utilisation, une fois que l’ensemble
des tickets d’incidents d’implémentation sont résolus)
• L’hébergement Cloud ou SaaS, périodiquement, à la mise en production.
• La maintenance, périodiquement, à l’issue de la recette définitive, en considérant la période de garantie.
Conclusion: étapes de sélection
Ce qu’il faut retenir:

1. Conduire l’appel d’offre pour trouver une solution adaptée aux besoins commerciaux de l’institution et un partenaire offrant une qualité de
service et étant dans une dynamique de relation long-terme. Pas uniquement la meilleure solution technique.
2. Réduire le risque en réalisant une démonstration complète du produit sélectionné et une série de tests poussés sur les fonctions clés pour
l’institution. Identifier les gaps fonctionnels éventuels et les inclure dans la négociation.
3. Conduire la négociation sur les volets contractuels du contrat, en regardant dans le détail les volets de licence logicielle, de maintenance,
de support et d’hébergement
4. Conduire la négociation financière sur la base des contrats, en gardant en tête le coût total de possession à 5 ans de la solution et le
calendrier de paiement
Contact
Yoann GUIRIMAND – PHB Developement
[email protected]

METHODE Réussir Sa Négociation de Contrat SIG CLOUD

Transféré par

Droits d'auteur :

Formats disponibles

METHODE Réussir Sa Négociation de Contrat SIG CLOUD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

METHODE Réussir Sa Négociation de Contrat SIG CLOUD

Transféré par

Droits d'auteur :

Formats disponibles

Système Informatisé de Gestion en Cloud

Eléments-clés pour réussir sa négociation contractuelle et financière

• Expression des besoins

L’appel d’offre permet la mise en concurrence de différents fournisseurs de solutions.

• Faiblesses Robustesse Mobilité: agents

Fournisseur #1 Fournisseur #2 Fournisseur #3 Fournisseur #4 Fournisseur #5 Fournisseur #6

30%* 63%* 54%* 72%* 78%* 16%*

Fournisseur #1 Fournisseur #2 Fournisseur #3 Fournisseur #4 Fournisseur #5

Note: il est fortement recommandé d’annexer au contrat d’implémentation:

Infrastructure des agences et points de service A C I R C

Migration des données A, R I I C R R

• La maintenance logicielle comporte 2 composantes:

Virtualisation Virtualisation Virtualisation Virtualisation

Ce qu’il faut retenir:

Vous aimerez peut-être aussi