Jean-Marie LAPEYRE Le logiciel libre au sein du SI fiscal

Jean-Marie LAPEYRE
Directeur technique du système d'information fiscal
Direction générale des Impôts
Direction générale de la Comptabilité publique
Le logiciel libre au sein du SI fiscal
Version 1.0 2005-10-17T2305
Plan (I)
1. Présentation du Programme Copernic :
la refonte du système d'information fiscal
2. La politique informatique de l'administration fiscale
3. La stratégie en matière de logiciels libres
4. La confiance : pierre angulaire pour le
développement des services en ligne
COPERNIC : Enjeux
• Un système d'information unique pour les deux directions générales
en charge de la fiscalité directe (DGI, DGCP) rendu accessible aux
citoyens
• 1 milliard d'€ de budget complémentaire sur ~ 10 ans (2001-2009)
et ~ 60 projets
Consultations
Guichets
Opérations
courantes
Téléphone
Internet
Nouveaux
services
24
/
24 / 7
7
Autres
media
Déclarations
déposées
Renforcer l'efficacité des agents des deux
directions générales
Avis d'imposition
(IR, TH, TVA, IS, TF,
etc.)
Compte
Fiscal
Simplifié
Requêtes,
réclamations..
Paiements, délais
accordés...
Données de recoupement
Consultations
Saisies
Poste
de
Travail
Nouveaux
services :
• Infocentres
• Outils d'aide
à la décision
•…
Agents
Contribuables
Individus – Entreprises
Donner aux contribuables un accès global,
cohérent et simple à leur situation fiscale
nt n
a
d tio
n
pe nisa
é
Ind orga
'
l
de
COPERNIC : exemples (i)
Le portail fiscal, www.impots.gouv.fr
- Consulter, déclarer et payer ses impôts
- Calculer l’impôt sur le revenu
- Commander des imprimés
- Télécharger et/ou remplir
des formulaires fiscaux
- Poser des questions
Votre compte fiscal
COPERNIC : exemples (ii)
Les services aux particuliers
Consulter son dossier fiscal
Déclarer ses revenus
~ 3 800 000 télé-déclarations en 2005
( ~ 1 250 000 en 2004,
~ 600 000 en 2003,
~ 120 000 en 2002)
Paiement en ligne
de l’impôt sur le revenu, taxe d’habitation, taxes
foncières, et contributions sociales généralisées
Adhésions et modifications en ligne
(montant des prélèvements,changement de
situation…)
Plan (II)
1. Présentation du Programme Copernic :
la refonte du système d'information fiscal
2. La politique informatique de l'administration fiscale
3. La stratégie en matière de logiciels libres
4. La confiance : pierre angulaire pour le
développement des services en ligne
Politique informatique fiscale :
Des objectifs stratégiques
●
L'administration fiscale s'est doté, depuis le début de la décénie,
d'une politique informatique dont les axes stratégiques sont :
● La maîtrise du SI
ou être apte à rapidement adapter le système à des besoins fluctuants tout en
assurant la qualité du service rendu ;
●
La pérennité du SI
ou faire en sorte que les choix d'aujourd'hui nous permettent de maîtriser le
système demain ;
●
●
L'indépendance aux technologies et aux fournisseurs.
La démarche opérationnelle s'articule autour :
● D'un paradigme d'architecture fort ;
● De l'adoption systématique de normes et standards ;
● De l'utilisation rationnelle de logiciels libres.
Politique informatique fiscale :
Un paradigme (I)
•
La robustesse d'un système d'information est avant tout liée à la qualité du
paradigme de construction sur lequel il repose.
Un modèle très puissant est aujourd'hui accessible compte tenu des
technologies disponibles :
L'Architecture Orientée Service (SOA)
•
Le modèle, dans son acception la plus pure (telle que mise en oeuvre dans
Copernic), repose sur la distinction, dans un système d'information, des
« processus métiers » et des « services et données métiers élémentaires ».
Notions séparées car subissant des contraintes d'évolution souvent non
convergentes (la fragilité des modèles antérieurs pouvant être expliquée par le
fait de lier les deux notions dans une même entité : l'application).
Politique informatique fiscale :
Un paradigme (II)
~ 55M citoyens
~ 3M entreprises
Les processus métier et
l'organisation peuvent
évoluer indépendamment
des services métiers
élémentaires et des données
Les données métier peuvent
toujours
rester cohérentes
et peuvent être atteintes
par n'importe quel processus
à tout instant
~100K agents
Portails
...
Modules de
Pilotage des
activités métier
Données
Ensemble
cohérent
d'activités
métier
Modules de
services métier
Services
Règles
métier
Interactions
...
Pré-requis impératif :
Toute interaction doit être
réalisée selon un
protocole normalisé et
standard
Plan (III)
1. Présentation du Programme Copernic :
la refonte du système d'information fiscal
2. La politique informatique de l'administration fiscale
3. La stratégie en matière de logiciels libres
4. La confiance : pierre angulaire pour le
développement des services en ligne
Politique informatique fiscale :
Quelle place pour le logiciel libre ?
(I)
●
Pourquoi considérer les logiciels libres pour la refonte de
l'informatique fiscale ?
– Conformité aux normes solutions de référence
– Modularité
 adaptables aux besoins
– Accès non exclusif
 corrections rapides
– Flexibles et adaptables  possibilités d'expérimentation
– Pas de coût d'entrée
 pas besoin de contrat public a priori
Politique informatique fiscale :
Quelle place pour le logiciel libre ?
(II)
Excellent respect
des normes et standards et
grande flexibilité d'utilisation
2000
Expériences de mise en oeuvre
très positives
Option d'utilisation ouverte
• ~ 4000 serveurs linux déployés
• Administration Système entièrement
basée sur du logiciel libre (Nagios, MRTG)
• Infrastructure production basée sur du
logiciel libre (Apache, JBoss)
• Plate-forme de développement basée sur
du logiciel libre (Eclipse)
Preuve d'un coût de possession
très faible (économie d'au moins 90%)
Support mature sur le marché
Choix stratégique :
2004
Le logiciel libre est désormais
le choix par défaut
pour toutes les applications fiscales
Politique informatique fiscale :
Quelle place pour le logiciel libre ?
(III)
●
Première expérience majeure très positive :
−
−
−
●
L'utilisation, depuis début 2001, de GNU/Linux pour supporter
l'application ILIAD de gestion de la fiscalité personnelle (gestion de
34.000.000 de contribuables, 23.000 utilisateurs) ;
Aucun incident système constaté depuis le déploiement ;
C'est l'infrastructure majeure de l'informatique fiscale dont le coût de
possession est, de loin, le plus faible.
Seconde expérience majeure : le marché J2EE (voir infra)
L'appel d'offre J2EE :
Contexte
●
Choix préalables (fin 2002) :
−
−
Orientations technologiques :
Produit choisi
pour les « conteneurs » Web (servlet/JSP)
●
Java / J2EE & WebServices
:
Apache / Tomcat
−
Besoins non couverts :
Impl. conteneur EJB unique
+ Support
+ Assistance au devt et exploit.
−
Produits multiples déjà utilisés :
WebSphere, WebLogic, Oracle, JBoss
Lancement d'un appel d'offre :
−
−
Partie ferme : logiciel – licence de parc, support et maintenance ;
Mise en concurrence libre / propriétaire (AO neutre)
Partie variable : prestations de monitorat et d'assistance (dont migration).
L'appel d'offre J2EE :
Dépouillement
●
Principaux critères de dépouillement de l'appel d'offre :
−
−
−
●
●
Conformité du produit aux exigences (normes) et performances ;
Qualité des intervenants et de l'organisation mise en place ;
Niveau d'engagement contractuel et prix.
L'évaluation de la qualité du produit et des intervenants a
été effectuée sur la base d'une procédure de test (une
semaine par proposition), que tous les candidats ont
reconnu d'une exigence rare.
(fondée sur un outil développé en interne : 8 mois*homme).
La procédure de dépouillement est auditable.
L'appel d'offre J2EE :
Résultats de la consultation
●
6 offres ont été déposées dont 4 s'appuyant sur du logiciel libre :
− Produits « éditeurs » : BEA WebLogic et IBM WebSphere
− Produits libres :
Jonas proposé par Bull
JBoss proposé par CapGemini, ThalèsIS, Sema
●
●
Le classement final place les offres s'appuyant sur des produits libres
aux 1er, 2nd, 3ième et 5ième rangs.
le marché a été notifié en juin 2004 au groupt Atos Origin / JBoss Inc.
Le dépouillement a non seulement montré que les produits libres
rivalisent ou surpassent les produits éditeurs, y compris dans un
environnement technologique complexe comme J2EE, mais surtout
qu'une offre de support mature est disponible.
L'appel d'offre J2EE :
Coût
●
Le budget prévisionnel maximal annoncé de l'opération (sur trois ans)
était de 23M€.
L'évaluation a été effectuée à partir des prix publics de l'éditeur prétendant être leader,
appliqués à notre échelle (35M€), auxquels a été défalqué un rabais habituellement
constaté et ajouté une projection des coûts de l'assistance (2/3 du total).
●
●
Le contrat signé prévoit finalement un coût ferme d'environ 2.7M€ et une
partie variable de 3M€ au max.
Soit une diminution de coût d'au moins 75%.
Ces chiffres sont à rapprocher de la nature de l'engagement du
prestataire :
− Un problème bloquant doit être résolu en au plus 48h ;
− Aucun changement de version majeur ne peut être imposé ;
− Toute évolution doit être reversée à la communauté ;
− Des millions d'utilisateurs et des milliers de développeurs.
Marché de support global
●
●
Comme la prestation sur JBoss est parfaitement conforme à nos attentes, nous
étendons le modèle.
Un nouvel appel d'offre a été lancé.
Objet : support et assistance autour de l'ensemble des nombreux logiciels libres
utilisés par les plus grandes directions du ministère des finances, structurés par
l'approche de l'administration fiscale.
(une quinzaine de catégories rassemblant ~150 logiciels : OS, serveur web, serveurs
d'infrastructure, « frameworks » de développement, outils de sécurité, bureautique, etc.).
Le dépouillement confirme la très haute valeur de l'offre disponible mise en
oeuvre au sein des grandes SSII appuyées sur des acteurs spécialisés (SSLL)
et des constructeurs. Cet appel d'offre a été remporté par le groupement
CapGemini/Linagora/Bull (notification très prochaine).
●
Son montant prévisionnel est compris entre 15M€ et 50M€ dont :
−
4.3M€ au titre du support sur 3 ans.
Perspectives
●
●
Au final, l'introduction raisonnée de logiciels libres permet à l'administration
fiscale d'atteindre ses objectifs stratégiques en matière de politique
informatique tout en lui permettant de maîtriser un budget logiciel désormais
très largement inférieur à celui habituellement constaté sur des structures
similaires (dixit un audit externe ; diminution du « TCO » d'un facteur 10).
Notre stratégie d'ensemble fait l'objet d'un intérêt de plus en plus marqué
chez d'autres utilisateurs de taille comparable, publics et privés et à
l'international. Nous tâchons de leur expliquer notre démarche et de
partager avec eux nos expériences.
Nous travaillons notamment aujourd'hui avec l'ADAE pour que notre
investissement soit profitable à l'ensemble de la sphère administrative
(mutualisation de documentations techniques ou méthodologiques, partage
des logiciels ; mis sous licence appropriées – Creative Commons ou
CeCILL).
Plan (IV)
1. Présentation du Programme Copernic :
la refonte du système d'information fiscal
2. La politique informatique de l'administration fiscale
3. La stratégie en matière de logiciels libres
4. La confiance : pierre angulaire pour le
développement des services en ligne
Fonder la confiance
Politique d'utilisation des certificats
L'administration fiscale a largement
investi dans une politique d'utilisation
et de promotion des certificats
électroniques à des fin
d'authentification et de signature
numérique.
Si la normalisation est ancienne et
quelques outils sont matures pour les
utilisations les plus simples (adossé
à de la messagerie par exemple), il
n'en est pas de même pour des
utilisations plus exigeantes
Manques les plus flagrants dans l'offre :
• Système de validation de certificats.
• Signature en ligne ;
Administration de la Preuve.
Service de Validation de Certificats (SVC) - I
Synthèse des besoins
• Mettre en place une Autorité de Validation générique en mesure de
valider des certificats X.509 :
– validation des champs du certificats – RFC3280
– validation de non-révocation sur la base des
informations fournies par les AC
– RFC2560
– validation de la chaîne de certification
– traitement fonctionnel des erreurs
(VERCER)
(VALREV)
(VERCAC)
• dans un contexte multi-AC
 récupération régulière des LCR publiées par les AC
• dans un contexte multi-applicatif
 domaines de confiance et politiques de validation
• dans un contexte sécurisé
 intégrité : réponses signées par l’Autorité de Validation
 non-répudiation : archivage des politiques de validation par l’ADP
Service de Validation de Certificats (SVC) - II
Fonctionnement
selon une politique de validation
Validation des certificats :
dans un domaine de confiance
Contribution à la normalisation :
Concept repris dans le RFC SCVP
back-office
Service de Validation de Certificats (SVC) - III
Caractéristiques
• Implémentation utilisant quasi-exclusivement des composants libres
(à l'exception du SGBDR) :
– Linux RedHat AS ;
– Apache, Tomcat 5, JBoss 3.2.5-DGI (utilisation de JMS) ;
– Supervision par Nagios.
• 940 jours*homme d'investissement (2 versions dont une en
production) à ce stade ;
• Mise en oeuvre industrielle de normes récentes et novatrices ;
Conformité de l'implémentation à ces normes ;
Contribution à l'IETF pour la RFC sur RCVP.
Administration De la Preuve (ADP) - I
Synthèse des besoins
•
Gérer l'intégrité et la non-répudiabilité des éléments de preuve
(« assurer la force probante ») :
– La signature électronique sur le poste du client ;
– L’enregistrement des éléments constitutifs de la preuve ;
– La conservation long terme des éléments constituant la preuve
et son administration ;
– L’exploitation des éléments de preuve en cas de litige.
•
Dans un contexte :
– De très forte charge
(composant de la v2 de la télé-déclaration IR) ;
– De risque sur la généricité et l'interopérabilité
(chaque application demande du spécifique).
Administration De la Preuve (ADP) - II
Fonctionnement
Poste client
Navigateur
Téléprocédure
Module ADP
de signature
Composants ADP
de formulaires
Web
DMZ
SVC
Serveur ADP
Signature/
Vérification
Horodatage
Cinématique
Poste utilisateur
Zone usager
Document externe
(compostage )
1. Signature usager
Module de
signature
Zone de gestion
spécifique à l 'archivage
2. Vérification signature
Vérification et
construction des
paquets d 'archivage
6. Affichage AR
Console
Administration
4. Génération AR
Signature
Console
Rejeu
Archivage
3. Dépôt Déclaration
Dépôt
d'archivage
Archivage
(stockage et
indexation )
7. Ingestion
5. Dépôt AR
Déclaration
AR
Interfaces de
rejeu et
d'administration
Serveur ADP
Archivage/Rejeu
8. Rejeu
Administration De la Preuve (ADP) - III
Caractéristiques
• Implémentation utilisant quasi-exclusivement des composants libres
(à l'exception du SGBDR) :
– ...
– JBoss 3.2.5-DGI, Axis 1.1, JAXB, OpenTSA ;
– Supervision par Nagios.
• Mise en oeuvre industrielle de XadES ;
• Implémentation générique ;
Contractualisation des accès au gestionnaire de preuve ;
• Capacité importante de tenue à la charge.
Questions ?