Pourquoi les organismes de sécurité sociale devraient résister à la tentation du « fait-maison » technologique

1. Introduction

Les institutions publiques de sécurité sociale font de plus en plus face à des pressions pour moderniser leurs systèmes d’information tout en maîtrisant les coûts, en améliorant la qualité du service rendu et en respectant des cadres juridiques en constante évolution. Dans ce contexte, certaines organisations envisagent de développer en interne des logiciels d’entreprise, souvent motivées par l’insatisfaction à l’égard de prestataires précédents, par la perception d’une perte de contrôle, ou par la conviction qu’un développement interne serait moins coûteux et mieux aligné sur les besoins institutionnels. Cependant, une vaste littérature académique en génie logiciel, en systèmes d’information et en administration publique montre que les systèmes d’entreprise de grande échelle, critiques pour la mission, comptent parmi les catégories de projets informatiques les plus difficiles et les plus risquées, en particulier lorsqu’ils sont développés en interne par des organisations dont les compétences centrales se situent en dehors de l’ingénierie logicielle. Avec le temps, les efforts de développement interne aboutissent fréquemment à des coûts équivalents ou supérieurs aux alternatives commerciales, tout en exposant les institutions à des risques opérationnels, techniques et de gouvernance nettement plus élevés. Cet essai soutient que la décision de construire en interne des systèmes d’entreprise pour la sécurité sociale repose sur une sous-estimation systématique du coût total de possession, du risque institutionnel, de la complexité architecturale et des exigences d’adaptabilité à long terme.

2. Coût total de possession et économie des logiciels d’entreprise

Le concept de coût total de possession (Total Cost of Ownership – TCO) est bien établi dans la littérature académique sur l’économie des systèmes d’information. Le TCO dépasse les seuls coûts initiaux de développement et inclut la maintenance, l’infrastructure, les ressources humaines, les mises à niveau, l’adaptation à la conformité et, à terme, le remplacement du système. Boehm (1981) et Boehm et al. (2000) ont montré que la maintenance et l’évolution des logiciels représentent généralement 60 à 80 % des coûts totaux sur l’ensemble du cycle de vie, un résultat confirmé à de multiples reprises par des études ultérieures portant sur de grands systèmes d’information. Les organisations qui se concentrent principalement sur le budget de développement sous-estiment donc de façon systématique la charge financière réelle liée à la possession du système.

Dans le secteur public, ce problème est amplifié. Heeks (2006) montre que les projets informatiques gouvernementaux souffrent fréquemment d’un biais d’optimisme, où les estimations initiales de coûts ne tiennent pas compte des contraintes institutionnelles, des rigidités de la commande publique et des obligations de maintenance à long terme. À mesure que les systèmes vieillissent, les coûts augmentent fortement en raison de l’accumulation de dette technique et d’une dépendance croissante à des architectures héritées.

Surtout, les études comparatives sur les arbitrages « construire vs acheter » dans les grandes organisations ne mettent pas en évidence de preuve constante selon laquelle le développement interne réduit les coûts à long terme lorsque l’on intègre l’ensemble des dépenses sur le cycle de vie (Rostami et al., 2017). Au contraire, les coûts tendent à converger, tandis que les systèmes développés en interne présentent une variance plus élevée et un risque de pertes (downside risk) plus important.

3. La conception de logiciels d’entreprise comme capacité institutionnelle spécialisée

Une idée fausse centrale, à l’origine de nombreuses initiatives « fait-maison », est de supposer que les systèmes d’entreprise relèvent principalement d’un défi de programmation. La recherche académique en génie logiciel montre clairement que l’écriture de code est la partie la moins complexe du développement d’un système d’entreprise.

L’ouvrage fondateur de Brooks, The Mythical Man-Month (1975), a établi que la complexité logicielle croît de manière non linéaire avec la taille du système et le nombre d’interfaces organisationnelles. C’est toujours vrai aujourd’hui, malgré tous les outils désormais disponibles pour les développeurs et l’automatisation par des outils d’IA qui, à première vue, semblent accélérer considérablement le développement. La réalité fondamentale ne change pas : les systèmes d’entreprise modernes doivent prendre en charge :

• Des règles métiers configurables
• L’orchestration des workflows
• L’auditabilité et la traçabilité
• Un contrôle d’accès finement granulaire
• Des performances à grande échelle
• La compatibilité ascendante
• L’adaptabilité réglementaire
• L’interopérabilité au-delà des frontières institutionnelles
• La cybersécurité

Les développeurs ne peuvent implémenter que ce qui est spécifié. Concevoir des spécifications qui restent valables sur des décennies, malgré l’évolution des lois, des dynamiques démographiques et des technologies, exige une expertise architecturale profonde et un capital de connaissances institutionnelles accumulées que la plupart des administrations ne possèdent pas en interne.

Les études empiriques sur le développement de systèmes de grande échelle confirment que les organisations dépourvues de capacités architecturales matures subissent davantage de reprises (rework), une densité de défauts plus élevée et une obsolescence prématurée des systèmes (Boehm et al., 2000 ; Sommerville, 2016).

Listes de souhaits pilotées par les utilisateurs, dépendance au sentier et absence de discipline des meilleures pratiques

L’un des risques les plus omniprésents et les moins reconnus des applications d’entreprise développées en interne est que les exigences du système sont souvent dictées par des listes de souhaits d’utilisateurs reflétant des pratiques existantes, plutôt que par une conception de processus fondée sur des preuves, ancrée dans des meilleures pratiques internationales, des normes comptables, ou la soutenabilité à long terme du système.

La collecte des exigences comme reproduction institutionnelle

La littérature académique sur l’ingénierie des exigences montre de manière constante que les utilisateurs expriment leurs besoins en fonction des workflows actuels et des points de douleur, plutôt qu’en termes d’objectifs fonctionnels abstraits ou de capacités de système orientées vers l’avenir (Sommerville, 2016). Dans les administrations publiques, cette tendance est renforcée par l’inertie institutionnelle et la dépendance au sentier : les procédures, formulaires et pratiques de reporting existants deviennent implicitement traités comme des « exigences », plutôt que comme des contraintes de conception à remettre en question.

Heeks (2006) décrit ce phénomène comme l’automatisation du dysfonctionnement (automation of dysfunction), dans laquelle les systèmes d’information reproduisent fidèlement des processus organisationnels inefficaces ou obsolètes au lieu de les transformer. Lorsque les développeurs internes s’appuient principalement sur les retours des utilisateurs, le système résultant encode souvent dans la logique logicielle des compromis historiques, des contournements manuels et des pratiques comptables héritées.

C’est particulièrement problématique dans les institutions de sécurité sociale, où les procédures héritées peuvent être antérieures :
• aux normes modernes de comptabilité d’exercice (accrual),
• aux modèles intégrés de rapprochement contributions–prestations,
• aux mécanismes automatisés de conformité et d’audit,
• ou au traitement numérique de transactions à très grand volume.

En conséquence, les systèmes développés en interne optimisent fréquemment la familiarité plutôt que la correction, et renforcent des inefficiences existantes à grande échelle.

L’incapacité structurelle des équipes internes à dire « non »

Une différence critique, mais insuffisamment étudiée, entre des équipes de développement internes et des éditeurs de logiciels d’entreprise externes tient à une asymétrie de gouvernance. Les développeurs internes sont intégrés dans la hiérarchie organisationnelle. Ils rendent souvent compte, directement ou indirectement, aux mêmes managers et unités opérationnelles qui produisent les exigences. Des études académiques sur les départements informatiques internes montrent que cette proximité crée de fortes incitations à accepter les demandes des utilisateurs, même lorsque ces demandes entrent en conflit avec les meilleures pratiques, les principes d’architecture ou la soutenabilité à long terme (Keen, 1991 ; Heeks, 2006).

À l’inverse, des éditeurs expérimentés de logiciels d’entreprise disposent :
• d’une indépendance contractuelle,
• d’une responsabilité externe,
• et d’incitations réputationnelles liées à la performance du système à long terme sur plusieurs clients.

Cette indépendance structurelle permet aux éditeurs de refuser ou de contraindre des demandes de fonctionnalités qui violent des normes comptables, fragilisent l’intégrité des données, ou introduisent des risques de scalabilité et de performance. Les équipes internes, en revanche, manquent souvent à la fois de l’autorité institutionnelle et de l’isolation politique nécessaires pour dire non — surtout lorsque les demandes émanent de cadres opérationnels seniors ou de départements influents. Dire « non » est difficile et ne vous rend pas populaire dans une organisation, même si c’est dans l’intérêt du projet et de l’institution. Les projets qui ne disposent pas de leaders forts capables de dire « non » à la haute direction sont voués à subir une dérive fonctionnelle (feature creep) et à être tirés dans toutes les directions par différentes listes de souhaits d’utilisateurs, qui peuvent faciliter le travail d’un utilisateur, mais affectent directement et négativement le travail de nombreux autres. Les décisions sur les fonctionnalités et les priorités seront davantage guidées par l’influence et le pouvoir perçus des départements utilisateurs que par des priorités purement techniques et objectives.

Dérive fonctionnelle, dégradation architecturale et risque de performance

Les conséquences d’exigences non maîtrisées, pilotées par les utilisateurs, sont bien documentées dans la recherche en génie logiciel. La dérive fonctionnelle — l’accumulation progressive de fonctionnalités étroites et spécifiques à certains utilisateurs — constitue l’une des causes principales de l’érosion architecturale dans les grands systèmes (Brooks, 1975 ; Sommerville, 2016).
Dans les systèmes d’entreprise de sécurité sociale, cela se manifeste par :
• une personnalisation excessive des règles métiers,
• une logique dupliquée entre modules,
• des exceptions en « cas particulier » codées en dur dans les workflows,
• une logique de reporting intégrée dans les couches transactionnelles.

Ces choix de conception peuvent satisfaire des attentes immédiates, mais entraînent souvent de lourdes conséquences à long terme :
• dégradation des performances du système,
• complexification de la maintenance,
• réduction de la scalabilité sous de forts volumes de transactions,
• et diminution de la capacité d’adaptation aux changements législatifs futurs.

Une fois intégrées, ces fonctionnalités sont extrêmement coûteuses à retirer, car elles deviennent des dépendances opérationnelles. Rostami et al. (2017) notent que les grands systèmes développés en interne accumulent fréquemment de la dette technique précisément parce que des décisions de conception précoces ont été prises pour satisfaire des parties prenantes immédiates plutôt que pour préserver l’intégrité architecturale.

Conflits avec les normes comptables et les meilleures pratiques réglementaires

Une autre dimension critique concerne l’intégrité financière et la conformité. Les systèmes de sécurité sociale interfèrent directement avec des normes de comptabilité publique, des principes actuariels et des exigences d’audit. Les utilisateurs, toutefois, sont rarement experts dans ces domaines.

La recherche en gestion des finances publiques montre que le personnel opérationnel privilégie souvent la commodité du reporting local plutôt qu’un traitement comptable standardisé, ce qui conduit à des demandes qui :
• brouillent les distinctions entre concepts de trésorerie (cash) et d’exercice (accrual),
• compromettent les pistes d’audit,
• ou fragilisent le rapprochement entre contributions, passifs et paiements (OCDE, 2016).

Les développeurs internes, manquant à la fois d’une expertise comptable approfondie et de l’autorité nécessaire pour contester les utilisateurs, peuvent implémenter ces demandes malgré leurs risques à long terme. Les éditeurs externes, au contraire, ont tendance à imposer des modèles de données et des structures comptables standardisés précisément parce que leurs systèmes doivent satisfaire des auditeurs et des régulateurs dans plusieurs juridictions.

Perte d’exposition aux meilleures pratiques internationales

Plus important encore, le développement interne piloté par les utilisateurs isole l’organisation des effets d’apprentissage internationaux.
Les éditeurs de logiciels d’entreprise accumulent une connaissance issue de dizaines d’implémentations, de régimes juridiques et de modèles opérationnels. Cette exposition leur permet d’intégrer :
• des workflows de conformité éprouvés,
• des mécanismes optimisés de recouvrement des contributions,
• des moteurs de calcul de prestations scalables,
• et des schémas de détection de fraude issus d’expériences comparatives.

Les équipes internes, par définition, opèrent dans un seul contexte institutionnel. Sans étalonnage externe (benchmarking), les systèmes risquent d’être optimisés localement mais sous-optimaux globalement, manquant des opportunités d’adopter des pratiques plus efficaces ou plus robustes déjà validées ailleurs (Hanseth & Lyytinen, 2010).

Implications pour la viabilité à long terme du système

L’effet cumulatif des listes de souhaits, de mécanismes de refus faibles et d’une exposition limitée aux meilleures pratiques se traduit par une transformation progressive des systèmes d’entreprise en artefacts rigides et fragiles, coûteux à maintenir et difficiles à réformer.
Heeks (2006) souligne que de nombreux échecs informatiques dans le secteur public ne sont pas des effondrements spectaculaires mais des dégradations lentes : les systèmes « fonctionnent », mais minent progressivement les objectifs de politique publique par leur inflexibilité, leur opacité et l’augmentation des coûts d’exploitation.

Pourquoi ce risque est systémique et non accidentel

Crucialement, ce problème n’est pas dû à de mauvaises intentions ni à un manque de compétences. Il est structurel :
• Les utilisateurs sont experts des opérations actuelles, pas de la conception des systèmes futurs.
• Les développeurs internes sont responsables devant les utilisateurs, et non indépendants d’eux.
• Les meilleures pratiques des systèmes d’entreprise émergent de l’apprentissage interinstitutionnel, pas d’un développement isolé.
Sans contrepoids délibérés — rares dans les initiatives internes — le développement interne privilégie presque inévitablement la satisfaction à court terme au détriment de la résilience institutionnelle à long terme.

4. Risque post–mise en production : droit, échelle et évolution technologique

Un schéma récurrent dans l’informatique du secteur public est que les succès initiaux masquent une fragilité à long terme.

4.1 Évolution légale et des politiques

Les systèmes de sécurité sociale sont intrinsèquement pilotés par les politiques publiques. Les amendements législatifs exigent des modifications rapides et précises des formules de prestations, des règles d’éligibilité, des plafonds de cotisation, ainsi que de nouvelles obligations d’échange de données et de reporting. Les systèmes qui ne sont pas conçus autour de moteurs de politique configurables deviennent cassants, imposant des changements de code coûteux et augmentant le risque d’erreurs (Heeks, 2006). Lorsque le cabinet du Premier ministre appelle et veut savoir à quelle vitesse une nouvelle prestation peut être paramétrée et payée à 1 million de bénéficiaires, le directeur informatique ne devrait pas devoir partir chercher le développeur qui a récemment démissionné et qui était le seul à savoir comment modifier cette configuration de prestation.

4.2 Scalabilité et performance

Les décisions de base de données et d’architecture prises au début d’un projet peuvent contraindre fortement la scalabilité future. Les études sur les grands systèmes transactionnels montrent que l’ajout a posteriori de la scalabilité coûte nettement plus cher que sa prise en compte dès la conception (Sommerville, 2016). Lorsque les volumes de production augmentent, les limites architecturales deviennent des menaces existentielles plutôt que des inconvénients techniques. La période initiale de mise en production d’un système développé en interne est généralement encore truffée de corrections de bugs et, en raison d’une base de données et de volumes de transactions plus faibles, le système lui-même, indépendamment des bugs, peut sembler fonctionner correctement. Le véritable test survient lorsque les volumes croissent, que le nombre d’utilisateurs augmente et que, soudain, des problèmes de performance apparaissent que les développeurs internes n’ont jamais rencontrés auparavant. À moins que des architectes systèmes expérimentés aient été impliqués dès la conception initiale, ces problèmes de scalabilité peuvent provoquer des perturbations majeures.

4.3 Évolution technologique

Les langages de programmation, navigateurs, systèmes d’exploitation, bases de données et standards de sécurité évoluent en permanence. Le verrouillage par l’héritage (legacy lock-in) est l’un des modes d’échec les plus documentés des systèmes informatiques du secteur public (OCDE, 2016). Les organisations qui développent en interne manquent souvent de capacité de refactoring et de modernisation continue, ce qui entraîne une escalade des coûts ou un remplacement forcé du système. Comme tous les coûts sont supportés par l’organisation — autrement dit, il n’y a pas d’autres clients du même système pour aider à couvrir les coûts des mises à niveau et d’éventuelles réécritures dues aux changements technologiques — le coût de développement devient continu, sans fin et souvent imprévisible. Bien davantage que les frais de maintenance typiques de 10 à 20 % facturés par les fournisseurs de logiciels commerciaux.

5. Sécurité, protection des données et risque institutionnel

La sécurité n’est pas une fonctionnalité ; c’est un processus continu. Les systèmes de sécurité sociale gèrent certaines des données les plus sensibles détenues par l’État. La recherche académique montre que les défaillances de sécurité sont fortement corrélées aux capacités organisationnelles plutôt qu’à l’intention.

Anderson (2020) souligne qu’une conception sécurisée des systèmes exige des investissements soutenus dans la modélisation des menaces, les tests, la surveillance et la gouvernance. Les institutions publiques maintiennent rarement la profondeur d’expertise spécialisée nécessaire pour gérer cela en continu. Encore une fois, il est difficile pour une administration de sécurité sociale de recruter et de retenir des experts dans tous les domaines du génie logiciel ainsi que de la sécurité, qui est une discipline à part entière. Sécuriser le réseau et l’infrastructure existants est déjà un défi majeur en soi ; il n’y a guère de marge pour ajouter des points de défaillance potentiels supplémentaires avec des logiciels développés en interne pour des applications critiques.

En outre, des cadres réglementaires tels que le RGPD et des lois nationales comparables imposent des obligations strictes en matière de minimisation des données, d’auditabilité, de notification des violations et de contrôle des accès. Le non-respect de ces normes expose les institutions à une responsabilité juridique, à des dommages réputationnels et à des perturbations opérationnelles (OCDE, 2019).

6. L’intégration comme défi structurel, et non technique

Les systèmes modernes de sécurité sociale opèrent au sein d’écosystèmes institutionnels denses : administrations fiscales, banques, prestataires de santé, registres d’état civil et plateformes d’identité numérique. L’intégration n’est donc pas seulement technique ; elle est aussi organisationnelle et juridique.
La recherche sur les systèmes d’information interorganisationnels montre que la complexité de l’intégration augmente de manière exponentielle avec le nombre de parties prenantes impliquées (Hanseth & Lyytinen, 2010). Les systèmes qui ne sont pas explicitement conçus pour l’interopérabilité tendent à devenir cloisonnés, ce qui fragilise la cohérence des politiques et l’efficacité administrative. Concevoir cela exige, encore une fois, des experts en développement d’API — pas pour un petit site web, mais pour des applications d’entreprise — et ces API doivent être conçues pour la performance autant que pour la sécurité.

Les plateformes d’éditeurs bénéficient d’une expérience d’intégration accumulée dans différentes juridictions, tandis que les équipes internes font face à une courbe d’apprentissage abrupte à chaque nouvelle interface. Autrement dit, les bons éditeurs auront l’expérience et auront appris, au fil du temps, des leçons tirées d’innombrables clients utilisant leurs applications dans des environnements à fort volume transactionnel, alors que les équipes de développement internes seront, par définition, limitées à ce qu’elles rencontrent dans leur pratique quotidienne.

7. Coûts d’opportunité et concentration institutionnelle

Enfin, le développement logiciel en interne impose des coûts d’opportunité significatifs. Les organisations publiques disposent d’une attention managériale, d’une flexibilité budgétaire et d’un capital politique limités. Détourner ces ressources vers la gestion des risques d’ingénierie logicielle réduit la capacité à se concentrer sur les mandats fondamentaux : application de la conformité, adéquation des prestations, accessibilité des services et innovation en matière de politiques publiques.

Heeks (2006) note que de nombreux échecs informatiques publics proviennent non d’une incompétence technique, mais d’un surmenage institutionnel — des organisations qui tentent d’en faire trop en dehors de leur avantage comparatif.

8. Sur quoi les équipes informatiques de sécurité sociale devraient se concentrer à la place :

Capacités institutionnelles stratégiques au-delà du développement du système cœur

Si la littérature académique et empirique suggère que les organismes de sécurité sociale sont mal positionnés pour construire et maintenir en interne des logiciels d’entreprise de grande échelle, la question suivante est constructive plutôt que critique : sur quoi les équipes informatiques internes devraient-elles se concentrer à la place ? La recherche sur les systèmes d’information du secteur public souligne de plus en plus que les unités informatiques gouvernementales les plus efficaces sont celles qui agissent comme facilitateurs institutionnels plutôt que comme développeurs de produits. Leur valeur ne réside pas dans l’écriture du code applicatif cœur, mais dans l’orchestration du changement organisationnel, la protection de la continuité opérationnelle, la garantie de la sécurité et de la conformité, et l’exploitation des données et des outils numériques pour améliorer la prestation de services (Heeks, 2006 ; OCDE, 2016).

8.1 Avant et pendant l’implémentation : construire la préparation organisationnelle

Gestion du changement

L’un des constats les plus constants dans la recherche sur l’informatique publique est que l’échec organisationnel, et non l’échec technique, est une cause dominante d’implémentations de systèmes infructueuses. Le cadre de gestion du changement de Kotter (1996) souligne que les grandes transformations échouent lorsque les institutions sous-estiment la résistance des utilisateurs, l’inertie culturelle et l’anxiété opérationnelle induite par des changements majeurs. Heeks (2006) met également en avant les « écarts conception–réalité » (design–reality gaps) comme explication centrale des échecs des initiatives d’e-gouvernement.

En pratique, les équipes informatiques internes de sécurité sociale apportent le plus de valeur lorsqu’elles dirigent ou co-dirigent : la cartographie des parties prenantes, la planification de la communication, la coordination de la formation, la mesure de l’adoption et le travail quotidien de « traduction » entre les départements opérationnels et l’équipe projet du fournisseur. Cela réduit le risque que l’implémentation devienne un exercice purement technique déconnecté de la réalité institutionnelle.

Nettoyage des données et préparation à la migration

La qualité des données est l’un des risques les plus sous-estimés dans les implémentations de systèmes d’entreprise. Strong, Lee et Wang (1997) montrent que la qualité des données doit être comprise « en contexte », car le succès opérationnel dépend non seulement de l’exactitude des données, mais aussi de la manière dont les utilisateurs les interprètent, leur font confiance et les consomment. Pour les organismes de sécurité sociale, les données héritées contiennent souvent des doublons, des identifiants incohérents, des lacunes de cotisations et des exceptions non documentées.

Les fournisseurs peuvent apporter des outils et des méthodes, mais les équipes informatiques internes devraient piloter les activités de gouvernance et de préparation des données : conception des règles de validation, rapprochement des enregistrements avec des registres faisant autorité, création de tests d’acceptation de migration et coordination avec les responsables métiers pour valider les cas limites et les exceptions propres à l’histoire de l’institution.

Définition des exigences et gouvernance

Les équipes internes ne devraient pas chercher à « concevoir le produit » fonctionnalité par fonctionnalité. Leur rôle interne à plus forte valeur est plutôt de définir des principes, des contraintes et des exigences non fonctionnelles : gouvernance de la sécurité et des accès, besoins d’auditabilité, attentes de performance, contraintes d’intégration, règles de conservation des données et exigences juridiques. Cette approche s’aligne sur les meilleures pratiques en ingénierie des exigences, qui distinguent ce que les utilisateurs disent vouloir et ce que le système doit accomplir de manière fiable dans des conditions réelles (Sommerville, 2016).

En outre, les équipes internes peuvent contribuer à maintenir une discipline dans les discussions d’exigences et éviter qu’elles ne se transforment en listes de souhaits ou en demandes optimisées localement qui sapent les meilleures pratiques, l’intégrité architecturale ou la conformité réglementaire (Heeks, 2006 ; Keen, 1991).

8.2 Après l’implémentation : soutenir l’écosystème institutionnel

Support utilisateurs interne et médiation de la connaissance

La recherche sur les résultats des systèmes d’entreprise souligne de manière constante que les bénéfices dépendent fortement d’un support post-implémentation durable, de la stabilisation des processus et de l’apprentissage organisationnel (Markus, Tanis & van Fenema, 2000). Les équipes informatiques de sécurité sociale devraient construire un support de premier et de second niveau solide, maintenir des bases de connaissances internes et des supports de formation, et agir comme couche d’escalade et de triage afin que le bruit opérationnel ne submerge pas les pipelines de changements du fournisseur.

Sécurité, réseau et résilience opérationnelle

La sécurité est un processus continu qui exige une gouvernance institutionnelle et des contrôles opérationnels, et non seulement des fonctionnalités techniques (Anderson, 2020 ; OCDE, 2019). Les équipes internes devraient prioriser les pratiques de gestion des identités et des accès, la séparation des tâches, les contrôles des terminaux, les programmes de sensibilisation à la sécurité et les plans de réponse aux incidents, en coordination avec les entités nationales de cybersécurité lorsque cela s’applique.

Il est tout aussi important d’assurer la résilience du réseau et la surveillance de l’infrastructure, car de nombreuses interruptions de service proviennent de problèmes de connectivité, de configuration ou de défaillances opérationnelles plutôt que de défauts du logiciel cœur. Les équipes internes devraient maintenir des plans de redondance, une surveillance de la performance et des pratiques de supervision des services alignées sur les principes de stratégie gouvernementale numérique (OCDE, 2016 ; OCDE, 2020).

Planification de contingence, continuité d’activité et reprise après sinistre

Les opérations de sécurité sociale sont critiques. Les interruptions du traitement des cotisations ou du paiement des prestations peuvent rapidement devenir des crises sociales et politiques. Herbane (2010) montre que la préparation aux crises et la capacité de continuité sont des capacités organisationnelles nécessitant une planification, une gouvernance et des tests réguliers — et pas seulement de la documentation. Les équipes informatiques internes devraient diriger ou co-diriger la planification de la continuité, les exercices de reprise après sinistre, les procédures manuelles de secours et les protocoles de restauration afin que les obligations de service puissent être maintenues même lorsque les systèmes échouent ou que des dépendances externes se rompent.

8.3 Innovation à la périphérie : extensions, outils internes, entrepôts de données et canaux mobiles

Développement d’extensions et d’outils de productivité internes

Les équipes internes peuvent et devraient développer des extensions qui ne déstabilisent pas le système cœur : utilitaires de rapprochement, tableaux de bord internes, assistants de gestion documentaire et scripts d’automatisation. C’est plus soutenable lorsque cela est fait via des conceptions faiblement couplées — un enseignement établi dans la recherche sur les infrastructures informationnelles (Hanseth & Lyytinen, 2010). L’objectif est d’accroître la productivité interne sans créer des personnalisations ingérables à l’intérieur de l’application cœur.

Entrepôts de données et analytique

Une institution de sécurité sociale mature s’appuie de plus en plus sur l’entreposage de données et l’analytique pour améliorer le ciblage de la conformité, la détection de fraude, la prévision et l’appui aux politiques publiques fondées sur des preuves. Les équipes internes devraient piloter la gouvernance des données, les définitions de reporting, les pipelines d’entrepôt et l’habilitation analytique, en coordination étroite avec les unités actuarielles et de politique publique (OCDE, 2016).

Applications mobiles et canaux d’accès numériques

Les canaux orientés citoyens évoluent rapidement, et l’inclusion dépend de plus en plus de services numériques accessibles. L’Enquête des Nations Unies sur l’e-gouvernement souligne le rôle du gouvernement numérique dans la prestation inclusive des services et l’importance d’un accès multicanal, y compris mobile (Nations Unies, 2020). Les équipes informatiques internes peuvent apporter une valeur en concevant des stratégies de canaux, en prototypant des expériences citoyennes, en intégrant les API du fournisseur et en améliorant en continu l’utilisabilité sans déstabiliser le moteur transactionnel cœur.

9. Conclusion

La littérature académique en génie logiciel, en administration publique et en systèmes d’information converge vers une conclusion claire : construire et soutenir des logiciels d’entreprise de grande échelle est une activité hautement spécialisée comportant des risques structurels que les institutions publiques de sécurité sociale sont mal placées pour absorber.

Le développement interne ne réduit pas de manière fiable les coûts sur le cycle de vie du système et augmente souvent l’exposition à des défaillances de sécurité, de scalabilité et de gouvernance. À l’inverse, des éditeurs spécialisés amortissent les coûts de développement sur plusieurs clients, maintiennent une expertise architecturale dédiée et font évoluer les systèmes en continu en réponse aux changements juridiques et technologiques.

Pour les organismes de sécurité sociale, l’impératif stratégique n’est donc pas l’autonomie technologique, mais la résilience institutionnelle — atteinte en se concentrant sur les fonctions publiques essentielles tout en s’associant à des entités dont la compétence centrale est la conception et l’évolution de logiciels d’entreprise.

Références

Anderson, R. (2020). Security engineering: A guide to building dependable distributed systems (3rd ed.). Wiley.

Boehm, B. W. (1981). Software engineering economics. Prentice Hall.

Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D., & Steece, B. (2000). Software cost estimation with COCOMO II. Prentice Hall.

Brooks, F. P. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley.

Hanseth, O., & Lyytinen, K. (2010). Design theory for dynamic complexity in information infrastructures: The case of building Internet. Journal of Information Technology, 25(1), 1–19.

Heeks, R. (2006). Implementing and managing eGovernment: An international text. SAGE Publications.

Herbane, B. (2010). Small business research: Time for a crisis-based view. International Small Business Journal, 28(1), 43–64.

Keen, P. G. W. (1991). Shaping the future: Business design through information technology. Harvard Business School Press.

Kotter, J. P. (1996). Leading change. Harvard Business School Press.

Markus, M. L., Tanis, C., & van Fenema, P. C. (2000). Multisite ERP implementations. Communications of the ACM, 43(4), 42–46.

OCDE. (2016). Digital government strategies for transforming public services in the welfare areas. OECD Publishing.

OCDE. (2019). Digital security risk management for economic and social prosperity. OECD Publishing.

OCDE. (2020). The OECD digital government policy framework. OECD Publishing.

Office of the Inspector General. (2022). Les défis et réussites de la Social Security Administration en matière d’obtention de données pour déterminer l’éligibilité et les montants de paiement (A-01-21-51029). Social Security Administration.

Rostami, A., Sommerville, I., & Hammond, J. (2017). Build software or buy? A study on developing large-scale software. Journal of Systems and Software, 132, 191–208.

Sommerville, I. (2016). Software engineering (10th ed.). Pearson.

Strong, D. M., Lee, Y. W., & Wang, R. Y. (1997). Data quality in context. Communications of the ACM, 40(5), 103–110.

United Nations. (2020). United Nations e-government survey 2020: Digital government in the decade of action for sustainable development (with addendum on COVID-19 response). United Nations Department of Economic and Social Affairs.