Declaration des revenus par Internet

Bonjour,

On Mon, 4 Apr 2005, A. Caspis wrote:

La déclaration des revenus en ligne semble fonctionner à
merveille pour la plupart des utilisateurs (windows+IE).

C'est quand même le PC de Mme Michu, hein... Et ça marche aussi à
merveille sous Windows+Mozilla...

En revanche avec Linux et Mozilla, je ne m'en serais pas tiré
sans les conseils des utilisateurs qui ont essuyé les plâtres
les années précédentes:
- Upgrader le JRE.
- chmod a+w /usr/java/jre*/lib/ext/ (sauf pour les courageux
qui naviguent sous root...)
- LANG=en_US.ISO-8859-1 (l'applet ne sait pas signer l'UTF-8 ?)

Je n'ai pas décortiqué le code de l'applet, mais je pense qu'elle sait
signer de l'UTF-8 mais que par contre les serveurs de la DGI ne savent pas
qu'il s'agit d'UTF-8 (pas certain que ce soit indiqué dans le paquet).

- Toujours exécuter Mozilla dans le même répertoire, sinon
l'applet ne retrouve pas ses fichiers.

La même applet est utilisée pour les machines sous Windows et Unices. Je
ne sais pas si une applet a la possibilité de connaître le répertoire de
base de l'utilisateur courant ($HOME ou
getenv("HOMEDRIVE")+getenv("HOMEPATH") ou getenv("USERPROFILE")), alors je
pense qu'elle tente de créer/utiliser le répertoire teleir/certificats à
partir du répertoire courant.
Pas testé, mais je pense que si tu changes le répertoire courant dans ton
raccourci pour IE/Mozilla sous ton Windows préféré, tu auras le même
comportement sous Windows.

D'où quelques interrogations sur cette infrastructure lourde qui
mélange cookies, javascript, java et SSL, alors que les banques
et sites marchands se contentent de SSL et de mots de passe.

Pas les mêmes besoins.

- A t-elle une autre utilité que de garantir la non-répudiation
des déclarations ?

Oui, l'équivalent du cachet de la poste qui fait foi. Le but est que la
déclaration par Internet ait la même valeur que la déclaration papier:
- cachet de la Poste
- signature pour éviter la répudiation

- Est-ce raisonnable, sachant que l'utilisateur doit installer
une applet opaque (voire obfusquée) et lui donner accès en
lecture et écriture au disque, alors que la non-répudiation
exigerait que la DGI n'ait strictement aucun moyen d'accéder
à la clé privée de l'utilisateur ?

Difficile de faire sans. Est-ce que la DGI peut imposer à Mme Michu
d'installer et d'utiliser un Mozilla 1.7 ou plus, ou un vieux Netscape
(4.x), afin de bénéficier des fonctions crypto en Javascript
(crypto.signText(...)), et ainsi laisser Mme Michu utiliser sa carte à
puce avec son certificat bien protégé? Est-ce qu'on peut compter sur Mme
Michu pour formatter un mail correctement, bien proprement (pour qu'il
soit aisément parsable par une machine, sinon le gain est perdu), et
utiliser les fonctions de signature S/MIME de son logiciel favori, là
encore en utilisant éventuellement une belle carte à puce (ou autre plus
cher et mieux, si affinités)? Est-ce qu'on peut imposer à tout le monde
d'utiliser IE et coder un ActiveX pour faire le même travail?

Tu proposes quoi pour faire la même chose, en t'adaptant le plus possible
à l'audience la plus large?

Le fait est que rien n'est prévu dans les navigateurs pour faire ce dont
la DGI a besoin. Sauf dans les anciens Netscape (4.x), et Mozilla 1.7+, en
Javascript, où tout est beau, et même l'utilisateur peut voir ce qui est
réellement signé...

Alors attendre de savoir lequel entre la poule ou l'oeuf va aparraître en
premier, bof.

- Que sait-on de teleir_cryptolib.jar ?

Rien, sauf si tu la décompiles.

- Pourquoi le document à signer n'est-il jamais présenté
à l'utilisateur sous un format neutre et non ambigu ?
Il est vrai qu'on peut voir du XML (sans DTD) au milieu des
traces de débug dans la console Java.

Qu'appelles-tu format neutre et non ambigü? Les différentes pages que tu
consultes et les différents formulaires ne suffisent pas? Quel intérêt
pour Mme Michu de voir s'afficher une suite de A23456&B1=TRUE&... ?

La version user-friendly, c'est ce que tu vois à l'écran. La version
parsable par une machine, c'est ce que l'applet signe. Il n'y a pas de
juste milieu.

- Pourquoi l'accusé de réception n'est-il pas signé, lui ?

Mme Michu pourrait-elle le vérifier? Dans le monde papier, est-ce que tu
recois quelque chose?

- Ne pouvait-on pas obtenir les mêmes propriétés de sécurité
avec seulement SSL et les fonctions de gestion de certificats
du navigateur ? Un enregistrement d'un HTTP POST SSL avec
authentification forte du serveur et du client ne fournirait-il
pas à la fois la confidentialité, la signature non répudiable,
et l'accusé de réception également non répudiable ?

Non. Le SSL ne protège que la session en cours, pas les données. 15 jours
après ta déclaration, il n'est pas possible de s'assurer que c'est bien
toi qui a signé cette déclaration.

Le SSL est utilisé ici, avec authentification forte, ce qui te permet de
consulter ton dossier fiscal. La DGI n'a pas besoin de s'assurer 15 jours
après que c'est bien toi qui a consulté tel ou tel dossier, la
vérification est effectuée à la connexion. Par contre, la DGI a besoin de
conserver une preuve de ta déclaration. Dans le monde papier, c'est ta
signature manuscrite qui fait office de preuve, et elle t'est opposable.
Ici, il faut un mécanisme similaire, et dans le monde PKI, c'est une
signature avec ta clé privée. C'est comme ça.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Recherche de groupe de discution en français sur la santé.
Par exemple je connais nntp.wanadoo.fr.
Est ce qu'il en existe t'il d'autre.
-+- in GNU : le serveur de news se refait une santé -+-

Bonjour.

J'attendais justement que le débat soit lancé.

"A. Caspis" <a_caspis@yahoo.com> a écrit dans le message de news:
424f2a13$0$18961$636a15ce@news.free.fr...

La déclaration des revenus en ligne semble fonctionner à
merveille pour la plupart des utilisateurs (windows+IE).

A merveille c'est vite dit. Notamment quand vous n'avez pas installé de JVM
et désactivé Java pour des raisons de sécurité, vous restez sceptique en
voyant que votre clic sur le bouton de validation (pour l'obtention d'un
certificat) n'a strictement aucun effet. J'ai cru un bon moment que le
serveur était surchargé. Aucune alerte d'aucune sorte, il faut retourner sur
la page d'accueil et lire la notice "configuration requise" pour comprendre.
Or il est à craindre que le contribuable moyen de connaisse même pas le sens
local du mot "configuration", alors savoir s'il a une JVM...

[Linux et Mozilla]

Et donc avec Firefox sous Windows ça ressemble pas mal comme parcours

d'obstacles.

D'où quelques interrogations sur cette infrastructure lourde qui
mélange cookies, javascript, java et SSL, alors que les banques
et sites marchands se contentent de SSL et de mots de passe.

- A t-elle une autre utilité que de garantir la non-répudiation
des déclarations ?
[...]

Je crains que l'intérêt majeur du truc soit de faire toute l'opération en
ligne et dans un navigateur Web, y compris la partie hautement indécente en
termes de sécurité qui consiste à écrire un fichier à la racine de votre
disque système (et qui donc nécessite Java).

Je crois que l'on aurait pu imaginer bien plus simple, par exemple permettre
à l'utilisateur de télécharger lui-même le fichier "certificat", qui aurait
pu être plutôt un petit exécutable sur mesure capable de calculer un hash
sur les données de l'opération, lequel serait remonté par copier-coller...
Il y a des services de dépôt légal qui fonctionnent selon ce principe.

Certes c'est moins beau que quand tout est fait en ligne, mais vu la cuisine
avant que ça marche on n'est plus à quelques petites manips près...

Dans le même genre il y a un autre problème éthique avec le Trésor@Public :
quand vous effectuez un "Paiement unique" de votre impôt, l'ordre de
paiement est enregistré, mais ensuite vous devez télécharger une
autorisation de prélèvement à signer et faire passer à votre banque. Il
s'agit de la même autorisation de prélèvement explicitement illimitée que
pour le prélèvement automatique :-@
Et donc normalement pour demander sa résiliation après le prélèvement
"unique" (au cas où), vous avez une taxe à payer qui devrait être de l'ordre
de 5 euros, ceci pour chaque paiement unique :-(

4 * 5 = 20, sans parler du prix de votre temps perdu à faire des bidouilles.
Y gagne-t-on aussi sur le plan de la sécurité ?

Je pense que la démarche est bonne, mais je serais assez curieux de savoir
quelle SSII renommée a encore eu ce marché...

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Patrick 'Zener' Brunet wrote:

Bonjour.

J'attendais justement que le débat soit lancé.

"A. Caspis" <a_caspis@> a écrit dans le message de news:

La déclaration des revenus en ligne semble fonctionner à
merveille pour la plupart des utilisateurs (windows+IE).

A merveille c'est vite dit.

Salutations,

Au vu des questions soulevées ici je pense que l'on peut effectivemment s'en
poser ;-))

....

Je pense que la démarche est bonne, mais je serais assez curieux de
savoir quelle SSII renommée a encore eu ce marché...

Sans aller jusque là je me demande plutôt de quelle école était le stagiaire
qui l'a mis en place ;-D

Sans blague c'est probablement très bien fait mais d'une part ça me semble
lourd, sans compter que le(s ?) serveur(s) mis en place ne semble(nt)
absolument pas proportionné pour soutenir la charge. Et d'autre part bien
qu'ayant mené une procédure à priori au bout je n'ai RIEN qui me permette de
penser que cela s'est passé correctemment (je suis méfiant car je l'ai fait
sous Firefox), ni une page l'indiquant comme réussie à la fin (ça a boucle
sur la page pour rentrer dans la déclaration) ni un mail pour confirmer le
tout.

Bref, c'est joli ils se sont peut être assuré de plein de chose de *leur*
coté mais ils pourraient prévoir de rassurer *aussi* le contribuable.
Peut être qu'ils se sont dit que s'ils envoyaient un mail celui-ci serait
pris pour du pfishing-truc ?

Pour moi un concept de base de la sécurité c'est la communication.... et là
y'a comme un manque :o)
--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!

Sans blague c'est probablement très bien fait mais d'une part ça me semble
lourd, sans compter que le(s ?) serveur(s) mis en place ne semble(nt)
absolument pas proportionné pour soutenir la charge. Et d'autre part bien
qu'ayant mené une procédure à priori au bout je n'ai RIEN qui me permette de
penser que cela s'est passé correctemment (je suis méfiant car je l'ai fait
sous Firefox), ni une page l'indiquant comme réussie à la fin (ça a boucle
sur la page pour rentrer dans la déclaration) ni un mail pour confirmer le
tout.
perso à la fin de ma déclaration j'ai eu la possibilité de télécharger

un accusé de réception au format pdf...ce que j'ai fait...

--

@+
ERIC
http://ericzworkz.free.fr/wordpress

On Mon, 4 Apr 2005, Patrick 'Zener' Brunet wrote:

"A. Caspis" <a_caspis@yahoo.com> a écrit dans le message de news:
424f2a13$0$18961$636a15ce@news.free.fr...

La déclaration des revenus en ligne semble fonctionner à
merveille pour la plupart des utilisateurs (windows+IE).

A merveille c'est vite dit. Notamment quand vous n'avez pas installé de JVM
et désactivé Java pour des raisons de sécurité, vous restez sceptique en
[...]

Or il est à craindre que le contribuable moyen de connaisse même pas le sens
local du mot "configuration", alors savoir s'il a une JVM...

Est-ce qu'on parle bien du même contribuable qui aurait désactivé Java
pour des raisons de sécurité? ;)

Je crains que l'intérêt majeur du truc soit de faire toute l'opération en
ligne et dans un navigateur Web, y compris la partie hautement indécente en

L'intérêt est de proposer enfin une application grand public qui utilise
réellement de la crypto, des certificats X.509, une PKI, pour offrir les
mêmes garanties que la même déclaration faite sur papier. Ca fait des
années qu'on attend que les navigateurs intègrent des fonctions de
signature générique utilisables par script, et rien n'est proposé. Depuis
que je fais de la PKI (97) on en est réduit à proposer des modules
externes qui forcément ne satisfont pas tout le monde, et ne sont pas
transparents. Poule, oeuf, poule, oeuf...

Je crois que l'on aurait pu imaginer bien plus simple, par exemple permettre
à l'utilisateur de télécharger lui-même le fichier "certificat", qui aurait

Possible, en effet, puisqu'au final, le certificat est stocké sous la
forme d'un fichier PKCS#12 sur disque. Mais il faut également être capable
d'utiliser ce certificat. Et si un utilisateur fortuné et bien informé
s'amuse à générer sa clé privée sur un token, ce certificat est
inutilisable par une applet...

pu être plutôt un petit exécutable sur mesure capable de calculer un hash
sur les données de l'opération, lequel serait remonté par copier-coller...
Il y a des services de dépôt légal qui fonctionnent selon ce principe.

Allons allons. On est où là? J'ai quand même bien l'impression de poster
sur fr.comp.securite... Elle est où la signature pour la non-répudiation
dans ton schéma avec un hash?

Certes c'est moins beau que quand tout est fait en ligne, mais vu la cuisine
avant que ça marche on n'est plus à quelques petites manips près...

Sur le PC de Mme Michu, de base, ça fonctionne.

Je pense que la démarche est bonne, mais je serais assez curieux de savoir
quelle SSII renommée a encore eu ce marché...

Il y en a plusieurs...

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
j'ai pour habitude de mettre le post auquel je réponds sous le
mien et non au dessus et ce n'est pas de l'impolitesse envers vous il
faudra bien que vous vous y habituez
-+- MP in Guide du Neuneu d'Usenet : Le mépris par l'exemple -+-

C'est quand même le PC de Mme Michu, hein... Et ça marche aussi à
merveille sous Windows+Mozilla...
meme Mr Michu sous Linux il y arrive...

http://roozeec.over-blog.com/article-186715.html
...bon Ok Mr Michu connait un peu mieux sa machine... ;-)


--

@+
ERIC
http://ericzworkz.free.fr/wordpress

"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> wrote in
message news:42513fce$0$18949$636a15ce@news.free.fr...

Bonjour.

J'attendais justement que le débat soit lancé.

"A. Caspis" <a_caspis@yahoo.com> a écrit dans le message de news:
424f2a13$0$18961$636a15ce@news.free.fr...

La déclaration des revenus en ligne semble fonctionner à
merveille pour la plupart des utilisateurs (windows+IE).

A merveille c'est vite dit. Notamment quand vous n'avez pas installé de
JVM
et désactivé Java pour des raisons de sécurité, vous restez sceptique en
voyant que votre clic sur le bouton de validation (pour l'obtention d'un
certificat) n'a strictement aucun effet. J'ai cru un bon moment que le
serveur était surchargé. Aucune alerte d'aucune sorte, il faut retourner
sur
la page d'accueil et lire la notice "configuration requise" pour
comprendre.
Or il est à craindre que le contribuable moyen de connaisse même pas le
sens
local du mot "configuration", alors savoir s'il a une JVM...

Sans compter que windows XP SP1 (PCs vendus depuis mi-2003) ne contient plus
de machine virtuelle java par défaut.

Ensuite, pour la question, du certificat, je ne sais pas ce qu'il en est
pour les navigateurs basés sur gecko, mais IE gere très bien
l'authentification par certificats clients. Je ne vois vraiment pas pourquoi
ceux ci n'ont pas été utilisés...

A. Caspis wrote:

Un enregistrement d'un HTTP POST SSL avec
authentification forte du serveur et du client ne fournirait-il
pas à la fois la confidentialité, la signature non répudiable,
et l'accusé de réception également non répudiable ?

Honte à moi, c'est évidemment faux ; et même si on voulait
modifier SSL pour signer des hash de la session, il serait
certainement maladroit de le faire avec une clé qui est
utilisée également pour l'authentification...

Je reste quand même sceptique sur la confiance que l'on peut
avoir dans l'infrastructure de signature des déclarations IR.
Un simple échange d'emails signés serait plus transparent.

AC

A. Caspis wrote:
[snip problèmes techniques]

- A t-elle une autre utilité que de garantir la non-répudiation
des déclarations ?

Oui: la déclaration est électroniquement signée par le certificat généré pour le
contribuable, certificat limité dans le temps et révocable.
Ce certificat et cette signature ont une valeur légale.

Les authentifications utilisées par les banques et sites marchands n'en ont pas.
Le problème se pose d'ailleurs lourdement pour ces derniers, pour des
«acheteurs» indélicats, qui reçoivent le produit, puis nient l'avoir commandé:
la banque, faute de pouvoir prouver l'authenticité de la transaction (pas de
signature, pas de PIN), doit rembourser.

- Est-ce raisonnable, sachant que l'utilisateur doit installer
une applet opaque (voire obfusquée) et lui donner accès en
lecture et écriture au disque, alors que la non-répudiation
exigerait que la DGI n'ait strictement aucun moyen d'accéder
à la clé privée de l'utilisateur ?

- Que sait-on de teleir_cryptolib.jar ?

- Pourquoi le document à signer n'est-il jamais présenté
à l'utilisateur sous un format neutre et non ambigu ?
Il est vrai qu'on peut voir du XML (sans DTD) au milieu des
traces de débug dans la console Java.

- Pourquoi l'accusé de réception n'est-il pas signé, lui ?

Sur ces quatre points: oui, c'est vrai, mais:
a) les utilisateurs lambdas, qui vont reformater leur disque après le prochain
ver/virus (j'exagère, je sais, mais pas tellement), ne sont pas aptes ni à
comprendre, ni à gérer leurs clefs privées.

b) Si ça ne plait pas, il reste le papier.
Et, de toute manière, c'est toujours le papier qui fait foi en cas de contrôle:
il faut conserver les preuves de ce qu'on déclare.

- Ne pouvait-on pas obtenir les mêmes propriétés de sécurité
avec seulement SSL et les fonctions de gestion de certificats
du navigateur ? Un enregistrement d'un HTTP POST SSL avec
authentification forte du serveur et du client ne fournirait-il
pas à la fois la confidentialité, la signature non répudiable,
et l'accusé de réception également non répudiable ?

Il faut toujours fournir un certificat au client. Et, d'après ce que j'ai
entendu dire, il est *nettement* plus difficile de le faire de manière fiable,
chaque navigateur ayant sa propre méthode pour les importer (et je ne suis pas
sûr du tout que les navigateurs sachent s'authentifier, en tout cas, je ne l'ai
jamais vu faire).

Laurent

Bonjour.

"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0504041636020.21140@shining.seclogd.org...

On Mon, 4 Apr 2005, Patrick 'Zener' Brunet wrote:

"A. Caspis" <a_caspis@yahoo.com> a écrit dans le message de news:
424f2a13$0$18961$636a15ce@news.free.fr...

La déclaration des revenus en ligne semble fonctionner à
merveille pour la plupart des utilisateurs (windows+IE).

A merveille c'est vite dit. Notamment quand vous n'avez pas installé de
JVM

et désactivé Java pour des raisons de sécurité, vous restez sceptique en
[...]

Or il est à craindre que le contribuable moyen de connaisse même pas le
sens

local du mot "configuration", alors savoir s'il a une JVM...

Est-ce qu'on parle bien du même contribuable qui aurait désactivé Java
pour des raisons de sécurité? ;)

Je l'avais désactivée sur le PC de mon frangin qui est un hyper-novice et
qui se trouve à l'autre bout de la France. Maintenant il faut que je lui
explique par téléphone comment la réactiver, et le truc c'est que quand il
comprend pas il me récite le contenu intégral de chaque page Web et il
m'engueule en plus ! J'espère bien que je n'aurai pas à lui faire faire une
install lourde d'un package Java sinon on n'en est pas sortis !

Je crains que l'intérêt majeur du truc soit de faire toute l'opération
en

ligne et dans un navigateur Web, y compris la partie hautement indécente
en

L'intérêt est de proposer enfin une application grand public qui utilise
réellement de la crypto, des certificats X.509, une PKI, pour offrir les
mêmes garanties que la même déclaration faite sur papier. Ca fait des
années qu'on attend que les navigateurs intègrent des fonctions de
signature générique utilisables par script, et rien n'est proposé. Depuis
que je fais de la PKI (97) on en est réduit à proposer des modules
externes qui forcément ne satisfont pas tout le monde, et ne sont pas
transparents. Poule, oeuf, poule, oeuf...

Certes, par moments ça me rappelle même le Dr Frankenstein !

Je crois que l'on aurait pu imaginer bien plus simple, par exemple
permettre

à l'utilisateur de télécharger lui-même le fichier "certificat", qui
aurait

Possible, en effet, puisqu'au final, le certificat est stocké sous la
forme d'un fichier PKCS#12 sur disque. Mais il faut également être capable
d'utiliser ce certificat. Et si un utilisateur fortuné et bien informé
s'amuse à générer sa clé privée sur un token, ce certificat est
inutilisable par une applet...

pu être plutôt un petit exécutable sur mesure capable de calculer un
hash

sur les données de l'opération, lequel serait remonté par
copier-coller...

Il y a des services de dépôt légal qui fonctionnent selon ce principe.

Allons allons. On est où là? J'ai quand même bien l'impression de poster
sur fr.comp.securite... Elle est où la signature pour la non-répudiation
dans ton schéma avec un hash?

Pour résumer mon point de vue, un navigateur Web n'est pas supposé accéder
ni en lecture ni (encore moins) en écriture, à une quelconque donnée de la
machine cliente (sauf éventuellement des données à lui qui viennent du Web
et sont susceptibles d'y retourner en respectant normalement certaines
conditions - ie les cookies).
Certes les ActiveX, Java et certains composants DCOM standards permettent de
passer outre, mais c'est en soi un trou de sécurité bien connu.

Donc je pars du principe que toute donnée devant résulter en un fichier
durable (hors-session) doit être mise en oeuvre de manière volontaire et
consciente par l'utilisateur. D'où la procédure qui consisterait à :
- importer par téléchargement "manuel" un fichier "certificat du client"
construit sur mesure par le serveur durant une première session sécurisée,
- faire sa saisie de déclaration dans le cadre d'une session sécurisée, à
l'intérieur de laquelle on peut de même à la fin récupérer par
téléchargement un fichier récapitulatif de la saisie,
- importer au préalable par téléchargement un module exécutable adapté au
système, et capable de fusionner le certificat, le récapitualtif, la date,
etc., et de générer avec tout ça un pattern textuel avec checksum et tout,
que l'utilisateur pourrait copier et coller dans un champ de formulaire de
la session sécurisée, ou alternativement on pourrait passer par un fichier à
uploader sur le serveur.

Il me semble qu'en procédant ainsi, on peut obtenir la même qualité de
signature qu'avec la méthode actuelle, mais sans utiliser des solution
d'accès aux fichiers de données par le navigateur, ce qui constitue le
problème technique majeur dont la solution actuelle relève du "hack
légitime".
Pour info, j'ai pas mal tourné autour de ce problème, et notamment par
exemple j'ai fait une maquette de site Web
où des records de données sont mémorisés d'une fois à l'autre : j'ai fait du
javascript qui rédige un javascript qui peut être réinclus la fois d'après,
mais pour figer ce code je demande à l'utilisateur d'ouvrir le fichier
Machin.txt avec le BlocNotes de Windows et de copier-coller dedans le
contenu intégral "du champ ci-dessous".
Le faire directement depuis le code de la page relève du hack et on imagine
ce que certains feront (et font déjà quand on l'active) d'une telle
possibilité standard.

D'où cette conclusion qui suivait selon laquelle un peu de manip manuelle
serait finalement plus raisonnable. Du moins tant que le navigateur Web
obéira mieux au monde extérieur qu'à l'individu assis devant l'écran.

Certes c'est moins beau que quand tout est fait en ligne, mais vu la
cuisine

avant que ça marche on n'est plus à quelques petites manips près...

Sur le PC de Mme Michu, de base, ça fonctionne.

J'ai passé Ad-Aware sur un PC de ce genre l'an dernier : 497 saloperies dont
185 critiques. Et ils ont été gentils, elle pouvait encore s'en servir (et
eux aussi bien sûr) :-)

Je pense que la démarche est bonne, mais je serais assez curieux de
savoir

quelle SSII renommée a encore eu ce marché...

Il y en a plusieurs...

C'est encore pire alors :-)

Croyez bien que je le regrette sincèrement.
Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/