Approvisionnement gouvernemental en logiciels : guide pratique pour les agents publics
Approvisionnement gouvernemental en logiciels : guide pratique pour les agents publics Utilisez un appel d’offres uniquement lorsque vous devez évaluer des facteurs autres que le prix. Dans tous les autres cas, une demande de devis ou un contrat-cadre de la GSA vous permet de conclure le contrat plus rapidement, avec une moindre exposition aux contestations.
Guide pratique pour les agents publics sur l’approvisionnement gouvernemental en logiciels
Utilisez un appel d’offres uniquement lorsque vous devez évaluer des facteurs autres que le prix. Dans tous les autres cas, une demande de devis ou un contrat-cadre de la GSA vous permet de conclure le contrat plus rapidement, avec une moindre exposition aux contestations. Trois garanties s’appliquent à toute acquisition de logiciels du secteur public, quelle que soit la procédure choisie : conformité au FAR, posture de sécurité documentée (alignement sur FedRAMP, FISMA ou NIST SP 800-53) et critères d’évaluation défendables et établis à l’avance.
Vos prochaines étapes immédiates :
-
Réalisez une étude de marché pour vérifier l’existence de solutions commerciales avant de rédiger des exigences sur mesure.
-
Effectuez une vérification de la référence de sécurité par rapport à la catégorisation FISMA de votre organisme et aux exigences d’autorisation FedRAMP.
-
Faites intervenir rapidement votre agent chargé des contrats ou une équipe d’approvisionnement assisté si les exigences sont complexes ou les délais serrés.
Table des matières
-
Quel type de procédure convient à votre approvisionnement gouvernemental en logiciels ?
-
À quoi ressemble réellement le cycle de vie de l’approvisionnement en logiciels ?
-
Comment rédiger les exigences et élaborer une matrice de notation défendable ?
-
SaaS/solutions commerciales prêtes à l’emploi ou développement sur mesure : comment choisir ?
-
Quelles exigences de sécurité et de conformité s’appliquent aux logiciels gouvernementaux ?
-
Quand faut-il recourir à des services d’approvisionnement assisté ?
-
Liste de contrôle de la diligence raisonnable envers les fournisseurs et signaux d’alerte
-
À quoi ressemblent des délais réalistes et le coût total de possession ?
-
Comment Ridiculous Engineering accompagne les acheteurs publics
Quel type de procédure convient à votre approvisionnement gouvernemental en logiciels ?
Le choix entre une demande d’information, une demande de devis et un appel d’offres est la première décision qui détermine tout ce qui suit. Si vous vous trompez, vous risquez soit de surdimensionner un achat simple, soit de sous-spécifier un achat complexe.
| Procédure | Idéal pour | Quand l’utiliser |
|---|---|---|
| Demande d’information | Étude de marché uniquement | Avant la finalisation des exigences ; aucun marché n’est attribué |
| Demande de devis | Périmètre bien défini, axé sur le prix | Solutions commerciales prêtes à l’emploi/SaaS avec spécifications connues, achats de faible montant |
| Appel d’offres | Évaluation multifactorielle | L’approche technique, les performances passées ou la prestation de services comptent |
| GSA MAS / OneGov | Achats informatiques pré-négociés | Attribution plus rapide, conditions de sécurité cohérentes, tarification selon le volume |
| Coopératif / rattachement à un contrat existant | Rapidité, contrat existant | Le périmètre et les prix doivent être alignés ; une vérification préalable est requise |
Les programmes d’achat de la GSA regroupent les dépenses informatiques courantes dans des dispositifs pré-négociés et prêts à satisfaire aux exigences de conformité. Pour de nombreux achats de logiciels, une commande passée via un Multiple Award Schedule (MAS) de la GSA est plus rapide et présente moins de risques qu’un appel d’offres autonome.
Le rattachement au contrat d’une autre agence peut réduire de plusieurs semaines les délais d’approvisionnement, mais il faut confirmer que le périmètre du contrat initial couvre votre cas d’utilisation, que les prix restent compétitifs et que les certifications de sécurité du fournisseur sont toujours à jour. C’est lorsqu’on omet cette vérification que le rattachement à un contrat existant échoue.
Conseil pratique : N’utilisez les appels d’offres que lorsque vous devez évaluer des facteurs autres que le prix. Recourir par défaut à un appel d’offres pour chaque achat de logiciel ajoute des mois et accroît le risque de contestation sans améliorer les résultats.
À quoi ressemble réellement le cycle de vie de l’achat de logiciels ?
Chaque phase produit un livrable précis. En omettre une signifie généralement devoir y revenir plus tard, à un coût plus élevé.
| Phase | Livrable clé | Responsable principal |
|---|---|---|
| Exigences et étude de marché | Rapport d’étude de marché, document des exigences | Responsable du programme ou responsable technique |
| Mise en concurrence | Demande de devis, appel d’offres ou demande de commande | Agent chargé des marchés publics |
| Évaluation | Propositions notées, note de consensus | Comité d’évaluation + agent chargé des marchés publics |
| Attribution | Contrat / commande subséquente | Agent chargé des marchés publics |
| Mise en œuvre | Plan de test d’acceptation, dossiers de déploiement | Responsable technique + fournisseur |
| Gestion du contrat | Rapports de performance, journal des modifications | Agent chargé des marchés publics + bureau du programme |
Les délais varient considérablement. Une commande SaaS simple passée via un calendrier de la GSA peut être finalisée en quelques semaines. Un appel d’offres concurrentiel pour une plateforme personnalisée prend généralement plusieurs mois entre la définition des exigences et l’attribution, la mise en œuvre ajoutant des mois supplémentaires selon le périmètre. La plupart des retards surviennent lors de la définition des exigences et de l’évaluation, et non lors de la mise en concurrence.
L’erreur la plus coûteuse dans l’acquisition de logiciels du secteur public consiste à lancer la mise en concurrence avant que les exigences soient stabilisées. Les agences qui consacrent deux à quatre semaines à une étude de marché structurée raccourcissent systématiquement la durée globale de leur cycle d’achat.
Comment rédiger les exigences et élaborer une matrice de notation défendable ?
Les exigences axées sur les résultats décrivent ce que le système doit accomplir, et non la manière dont il doit être construit. « Le système doit traiter 10 000 demandes de permis par mois avec une disponibilité de 99,5 % » est testable. « Le système doit être moderne et convivial » ne l’est pas.
Séparez les critères obligatoires de réussite ou d’échec des éléments notés. Les critères obligatoires éliminent les offres non conformes avant le début de la notation. Les éléments notés permettent de différencier les offres conformes.
| Facteur d’évaluation | Pondération | Notes d’évaluation |
|---|---|---|
| Approche technique | — | Méthodologie, architecture, plan d’intégration |
| Performances passées | — | Références, périmètre similaire, récence |
| Niveau de sécurité | — | Statut FedRAMP, contrôles NIST, réponse aux incidents |
| Prix / coût total | — | Licences, mise en œuvre, maintenance continue |
Un tableau de conformité appliqué de manière cohérente à tous les soumissionnaires réduit le risque de recours et facilite la documentation de la décision d’attribution.
Bonnes pratiques essentielles pour des évaluations prêtes à être auditées :
-
Arrêtez les critères d’évaluation et les pondérations dans l’appel d’offres avant de recevoir les propositions.
-
Utilisez un processus d’évaluation fondé sur le consensus, avec les notes individuelles documentées avant la discussion du comité.
-
Assurez le contrôle des versions de toutes les modifications de l’appel d’offres et de toutes les feuilles d’évaluation.
Conseil pratique : Documentez chaque décision de notation par une phrase justificative. « Le soumissionnaire A a obtenu 4/5 pour l’approche technique parce que… » est la phrase qui permet de gagner un recours.
SaaS/COTS ou développement sur mesure : comment choisir ?
La réponse honnête est que la plupart des agences se tournent par défaut vers les COTS lorsqu’une solution sur mesure serait justifiée et commandent parfois des développements sur mesure alors qu’un produit commercial aurait parfaitement convenu. Les compromis entre les logiciels open source et propriétaires suivent une logique similaire.
| Dimension | SaaS / COTS | Développement sur mesure |
|---|---|---|
| Idéal pour | Flux de travail courants, cas d’utilisation éprouvés | Processus uniques, intégration avec des systèmes existants, besoins propres à la mission |
| Coût total de possession | Coût initial inférieur ; les frais d’abonnement s’accumulent | Coût initial supérieur ; coût à long terme inférieur si la solution est bien entretenue |
| Délai de déploiement | De quelques semaines à quelques mois | De quelques mois à plusieurs années (une approche modulaire raccourcit ce délai) |
| Risque de dépendance vis-à-vis d’un fournisseur | Élevé ; la portabilité des données doit être négociée | Faible si vous détenez les droits de propriété intellectuelle et le code source |
| Niveau de sécurité | Autorisation FedRAMP disponible pour les principales plateformes | Doit être intégrée ; nécessite un alignement sur la norme NIST SP 800-53 |
| Modèle de maintenance | Mises à jour gérées par le fournisseur | Gérées par l’agence ou le prestataire |
| Flexibilité des licences | CLUF standard ; droits de modification limités | Droits complets négociables par contrat |
FAR, partie 39 recommande une contractualisation modulaire pour les grands projets informatiques, en répartissant le travail en lots plus petits afin de réduire les risques liés aux délais et aux aspects techniques. Ces recommandations s’appliquent aussi bien aux développements sur mesure qu’aux mises en œuvre progressives de solutions COTS.
Conseil pratique : Lorsque vous acceptez une licence commerciale, examinez le CLUF pour repérer les clauses d’indemnisation avant de signer. La partie 12 du FAR déconseille d’accepter des conditions créant des obligations incompatibles avec le droit fédéral, notamment l’Anti-Deficiency Act.
Quelles exigences de sécurité et de conformité s’appliquent aux logiciels gouvernementaux ?
La sécurité n’est pas une préoccupation à traiter après l’attribution du marché. Elle doit figurer dans l’appel d’offres, les critères d’évaluation et le contrat.
Exigences minimales selon le type de système :
-
SaaS cloud : Autorisation FedRAMP au niveau d’impact correspondant à vos données (faible, modéré ou élevé). Vérifiez le statut actuel de l’autorisation sur la place de marché FedRAMP avant l’attribution du marché.
-
Sur site ou hybride : Documentation de conformité FISMA et une Authority to Operate (ATO) à jour, ou un plan pour en obtenir une.
-
Tous les logiciels : Correspondance avec les familles de contrôles NIST SP 800-53 pertinentes, notamment le contrôle des accès (AC), la réponse aux incidents (IR) et la gestion de la configuration (CM).
Clauses contractuelles à exiger :
-
Droits sur les données et propriété de celles-ci (le gouvernement conserve à tout moment les droits sur ses données).
-
Délais d’application des correctifs et de réponse aux vulnérabilités (l’application des correctifs critiques sous 30 jours est une norme courante).
-
Exigences de notification des incidents (une notification sous 72 heures est un seuil courant).
-
Formulation relative à la limitation de responsabilité, examinée au regard du droit fédéral.
Le niveau de sécurité est un facteur d’évaluation, pas une simple case à cocher. Un fournisseur disposant d’une autorisation FedRAMP Moderate et d’un plan documenté de réponse aux incidents présente un risque nettement inférieur à celui d’un fournisseur s’appuyant sur une auto-attestation et une politique de sécurité vague.
Les CLUF commerciaux contiennent fréquemment des conditions d’indemnisation ou de garantie incompatibles avec les règles fédérales d’achat. La partie 12 du FAR demande aux agents chargés des contrats d’acquérir les logiciels commerciaux sous des licences publiques standard lorsque celles-ci sont conformes au droit, et de signaler les conditions qui ne le sont pas. Un examen juridique avant la signature n’est pas facultatif pour les contrats de grande valeur ou portant sur des données sensibles. En ce qui concerne la les exigences de sécurité fédérales en matière de confiance zéro et applicables aux prestataires, le niveau d’exigence a considérablement augmenté ces dernières années.
Quand devez-vous recourir aux services d’acquisition assistée ?
Une acquisition assistée consiste à faire appel à un organisme contractant tiers, tel qu’un centre d’excellence de la GSA ou le service des contrats d’une autre agence, pour mener la procédure d’achat en votre nom. Votre agence conserve la responsabilité technique et l’autorité sur les exigences ; l’équipe chargée de l’acquisition assistée s’occupe de l’appel d’offres, de l’appui à l’évaluation et de l’administration du marché après son attribution.
Les services d’acquisition assistée de la GSA réduisent la charge administrative et apportent des dispositifs pré-négociés ainsi qu’une expertise en matière de conformité pour les achats complexes. Ils sont particulièrement utiles lorsque votre agence manque de capacités contractuelles, lorsque le besoin implique une expertise informatique spécialisée ou lorsqu’un calendrier serré rend impraticable une procédure complète menée en interne.
L’acquisition assistée n’est pas un moyen de contourner la supervision. Elle permet de réorienter l’énergie de votre équipe vers ce que seule votre agence peut faire : définir les exigences, fixer les critères d’acceptation et gérer la performance du fournisseur après l’attribution du marché.
Conseil pratique : Conservez un responsable technique de votre bureau de programme pendant toute acquisition accompagnée. L’équipe chargée des contrats gère le processus ; votre équipe est responsable du résultat.
Liste de contrôle de la diligence raisonnable des fournisseurs et signaux d’alerte
La diligence raisonnable intervient avant l’attribution, et non après l’apparition d’un problème.
Liste de contrôle :
-
Vérifiez les références relatives aux performances passées pour des contrats d’une portée et d’une complexité similaires.
-
Confirmez que le statut d’autorisation FedRAMP ou la documentation FISMA est à jour.
-
Examinez les rapports SOC 2 de type II pour les fournisseurs SaaS traitant des données sensibles.
-
Vérifiez les indicateurs de stabilité financière (années d’activité, historique des contrats gouvernementaux).
-
Confirmez que les accords de niveau de service relatifs à l’application des correctifs et à la réponse aux incidents sont documentés et applicables.
| Durée du contrat | Norme minimale |
|---|---|
| Disponibilité du SLA | 99,5 % ou plus pour les systèmes critiques à la mission |
| Délai de réponse aux correctifs critiques | 30 jours à compter de la divulgation |
| Restitution des données à la résiliation | 30 jours, dans un format lisible par machine |
| Notification des incidents | 72 heures à compter de la découverte |
| Critères d’acceptation | Définis, mesurables et liés aux jalons de paiement |
Signaux d’alerte : des conditions opaques ou non négociables du CLUF, des clauses d’indemnisation qui transfèrent une responsabilité illimitée au gouvernement, une feuille de route produit qui n’a pas été mise à jour depuis plus d’un an et des engagements de niveau de service sans recours financier en cas de manquement. S’adosser à un contrat existant peut être rapide, mais ces vérifications s’appliquent toujours.
À quoi ressemblent des calendriers réalistes et le coût total de possession ?
| Type d’approvisionnement | Délai d’approvisionnement | Mise en œuvre | Stabilisation |
|---|---|---|---|
| SaaS via le catalogue GSA | Plusieurs semaines | Quelques mois | De plusieurs semaines à quelques mois |
| Appel d’offres concurrentiel, COTS | Plusieurs mois | Plusieurs mois | Plusieurs mois |
| Développement personnalisé (modulaire) | Plusieurs mois | De plusieurs mois à plus d’un an | Plusieurs mois |
Les facteurs de coûts cachés que les budgets omettent régulièrement : migration des données, intégration aux systèmes existants, remédiation de la sécurité avant l’ATO, formation des utilisateurs finaux et maintenance continue après la période contractuelle initiale. Une analyse du coût total de possession sur trois ans, incluant l’augmentation des coûts de licence et les frais de support, produit presque toujours un classement différent d’une comparaison des prix de la première année.
Conseil de pro : Structurez les contrats de développement sur mesure en incréments modulaires conformément à la partie 39 du FAR. Chaque incrément possède ses propres critères d’acceptation et autorisations de financement, ce qui limite l’exposition si les exigences changent en cours de projet.
Comment Ridiculous Engineering accompagne les acheteurs publics
Ridiculous Engineering accompagne les organisations gouvernementales et du secteur public aux étapes de définition des exigences, de livraison et de support à long terme d’un achat.
Des services qui répondent directement aux besoins des achats publics :
-
Définition des exigences et rédaction des spécifications techniques.
-
Conception d’architectures modulaires alignées sur les structures contractuelles de la partie 39 du FAR.
-
Développement sécurisé de logiciels sur mesure, avec alignement sur les contrôles du NIST SP 800-53.
-
Intégration de systèmes existants et développement d’API.
-
DevOps, mise en place de pipelines CI/CD et architecture cloud.
-
Mise en œuvre après attribution, tests et support de maintenance à long terme.
Les équipes chargées des achats peuvent faire appel à Ridiculous Engineering au moyen d’un énoncé des travaux dans le cadre d’un dispositif existant, en tant que sous-traitant après attribution, ou par l’intermédiaire d’une coopération pour une acquisition assistée conformément aux règles de l’agence. L’objectif reste toujours le même : vous aider à définir ce dont vous avez réellement besoin, à le construire correctement et à le maintenir en fonctionnement.
Points clés
Un achat public de logiciels efficace exige le type de procédure de mise en concurrence approprié, une posture de sécurité documentée et des critères d’évaluation défendables établis avant l’arrivée des propositions.
| Point | Détails |
|---|---|
| Adapter la procédure à la complexité | Utilisez une RFQ pour les achats axés sur le prix ; réservez la RFP aux évaluations multicritères afin de gagner du temps et de réduire le risque de contestation. |
| La sécurité est un facteur d’évaluation | Exigez une autorisation FedRAMP, un alignement sur le NIST SP 800-53 et des accords de niveau de service (SLA) de correction des vulnérabilités opposables dans chaque contrat logiciel. |
| Établir la notation avant de recevoir les propositions | Fixez les critères et les pondérations d’évaluation dans la procédure de mise en concurrence ; documentez chaque justification de notation afin d’être prêt pour les audits. |
| Utiliser des contrats modulaires pour les projets de grande envergure | La partie 39 du FAR recommande de diviser les grands projets informatiques en incréments afin de limiter les risques liés au calendrier et de préserver la flexibilité du financement. |
| Ridiculous Engineering comme partenaire technique | Ridiculous Engineering accompagne les acheteurs publics, de la définition des exigences à la mise en œuvre après attribution et à la maintenance à long terme. |
Ridiculous Engineering accompagne les équipes chargées des achats qui ont besoin d’un partenaire technique
Les responsables des achats publics savent souvent exactement quel résultat ils doivent obtenir et disposent de nombreuses orientations procédurales. Ce qui leur manque fréquemment, c’est un partenaire technique capable de traduire les exigences de mission en un système réalisable, sécurisé et maintenable, et qui comprend le fonctionnement réel des contrats publics.
Ridiculous Engineering propose du développement de logiciels sur mesure adapté aux dispositifs d’achat, des missions fondées sur un énoncé des travaux aux contrats de livraison après attribution. L’équipe couvre la définition des exigences, l’architecture sécurisée, l’intégration aux systèmes existants de l’agence et le support à long terme, sans les lourdeurs d’un grand intégrateur de systèmes ni le risque lié à un fournisseur qui disparaît après la mise en production.
Pour discuter de la manière dont Ridiculous Engineering peut accompagner votre prochain achat de logiciels, contactez-nous directement via la page des services de développement de logiciels sur mesure.
Sources faisant autorité et lectures complémentaires
-
FAR, partie 12 : Acquisition de produits commerciaux et de services commerciaux — régit le traitement des licences de logiciels commerciaux et les exigences d’examen des contrats de licence utilisateur final (EULA).
-
FAR, partie 39 : Acquisition de technologies de l’information — couvre la politique de contractualisation modulaire et les procédures d’achat informatique.
-
FAR 15.203 : demandes de propositions — définit la structure des demandes de propositions et les exigences minimales de contenu pour les acquisitions concurrentielles.
-
Programmes d’achat de la GSA — services d’acquisition assistée et solutions informatiques pré-négociées.
-
GSA OneGov — achats centralisés de logiciels pour des tarifs et des conditions de sécurité cohérents.
-
Marketplace FedRAMP — source officielle permettant de vérifier le statut d’autorisation des produits cloud.
-
Sous-partie 227.72 du DFARS — règles spécifiques à la défense concernant les droits relatifs aux logiciels informatiques et la documentation.
-
RFQ ou RFP dans les appels d’offres publics — analyse pratique des situations dans lesquelles chaque type de sollicitation s’applique.
FAQ
Quand faut-il utiliser une RFP plutôt qu’une RFQ ?
Utilisez une RFP lorsque des critères d’évaluation autres que le prix, tels que l’approche technique, les performances passées ou le niveau de sécurité, doivent être évalués. Pour les achats de logiciels bien définis où le prix constitue le principal facteur de différenciation, une RFQ est plus rapide et présente un risque de contestation moindre.
Qu’est-ce que FedRAMP et pourquoi est-ce important pour les achats de logiciels ?
FedRAMP est le programme fédéral d’autorisation des services cloud. Exiger une autorisation FedRAMP au niveau d’impact approprié (faible, modéré ou élevé) signifie que les contrôles de sécurité du fournisseur ont été évalués de manière indépendante, ce qui réduit la charge et l’exposition aux risques liés à l’ATO de votre organisme.
Que dit la partie 39 du FAR au sujet des grands projets informatiques ?
La partie 39 du FAR recommande la contractualisation modulaire pour les grandes acquisitions informatiques, en divisant le travail en incréments plus petits assortis de critères d’acceptation définis. Cela limite les risques liés au calendrier et préserve la flexibilité budgétaire si les exigences évoluent.
Comment l’acquisition assistée réduit-elle les risques liés aux achats ?
L’acquisition assistée transfère l’administration contractuelle à une équipe spécialisée, telle qu’un centre de la GSA, tandis que votre organisme conserve la responsabilité technique et le pouvoir de définir les exigences. Elle est particulièrement utile pour les achats informatiques complexes, les délais serrés ou lorsque les capacités internes en matière de passation de marchés sont limitées.
Ridiculous Engineering peut-il accompagner un achat public de logiciels ?
Oui. Ridiculous Engineering accompagne les acheteurs publics dans la définition des exigences, le développement personnalisé sécurisé, l’intégration des systèmes et le support post-attribution, selon une structure compatible avec les dispositifs d’achat courants, notamment les énoncés des travaux et les accords de sous-traitance.