Cet appel d'offre public est important car il a pour but de faire sauter deux verrous qui freinent l'adoption des logiciels libres.
Le premier verrou est le remplacement de la messagerie Exchange 5.5 et X400 par une messagerie open source. Le but est d'offrir au moins les mêmes fonctionnalités car elles se sont souvent intégrées à la culture d'entreprise.
Le deuxième verrou est de permettre l'usage des PDA et autres Pocket PC Windows dans un environnement hétérogène. Il faut savoir que ces petits appareils sont offerts indirectement par Microsoft aux dirigeants des grandes structures. Ces cadeaux sont empoisonnés car ces dirigeants exigent ensuite de pouvoir s'en servir, souvent au grand dam de leurs techniciens. En effet, il ne fonctionnent initialement qu'avec Outlook... qui ne fonctionne qu'avec Exchange... qui ne fonctionne qu'avec Windows... C'est ainsi que le petit cadeau entraîne le verrouillage des entreprises et des administrations.
Le projet, lancé dans la discrétion, n'en est pas moins énorme tant par sa taille (environ 100 000 postes seront concernés) que par son apport aux logiciels libres. Il y a fort à parier que Microsoft va utiliser comme d'habitude tous ses moyens de pression pour essayer de faire avorter le projet. Il n'y a pas d'URL directe et pérenne vers l'appel d'offre du ministère de l'intérieur.
Pour le consulter, il faut aller sur les site des marchés publics. On accède alors à l'annonce en remplissant les trois champs ci-dessous :
Référence de l'annonce
- Numéro de parution du BOAMP (ex : 63) .... 090
- Numéro d'une annonce (ex : 266) .... 268
- Date de publication d'une annonce .... 11/05/2006
Aller plus loin
- L'annonce (28 clics)
- Le Journal Officiel - Appel d'offres (59 clics)
- Consulter les annonces de marchés publics (39 clics)
# Des PDA OFFERTS dans la fonction publique ?
Posté par qdm . Évalué à 10.
(1) On va m'objecter que c'est un outil de travail, mais franchement, je ne suis pas sûr que ça tienne devant un juge mal luné (et à raison)
[^] # Re: Des PDA OFFERTS dans la fonction publique ?
Posté par salvaire . Évalué à 1.
[^] # Re: Des PDA OFFERTS dans la fonction publique ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
[^] # Re: Des PDA OFFERTS dans la fonction publique ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
Les cadeaux peuvent se faire de façon très détournée. Par exemple, il y a 30 ans, j'avais reçu de Hewlett-Packard une calculatrice car j'étais officiellement le premier client à être allé dans leur nouvelle agence. En réalité, j'étais leur plus gros client de l'époque et prescripteur pour l'usage des ordinateurs de bureau du type HP9825. Ce cadeau était équivalent à un PDA d'aujourd'hui mais il se suffisait à lui-même et n'avait aucun impact sur la politique d'équipement de mon entreprise.
Lutter contre les PDA aux interfaces non spécifiées, c'est identique à la lutte contre les formats propriétaires car dans les deux cas le but est de "fidéliser" les clients par un manque d'interopérabilité.
[^] # Re: Des PDA OFFERTS dans la fonction publique ?
Posté par qdm . Évalué à 2.
[^] # Re: Des PDA OFFERTS dans la fonction publique ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: Des PDA OFFERTS dans la fonction publique ?
Posté par Funix (site web personnel, Mastodon) . Évalué à 2.
https://www.funix.org mettez un manchot dans votre PC
# L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 7.
En effet, il m'a été donné de voir qu'il existe dans un de nos ministères des politiques de sécurité qui demandent aux serveurs de messagerie de bloquer les fichiers au format OpenDocument sous prétexte que l'XML n'est pas sûr et qu'un organisme de sécurité de l'État a déjà réussi à écrire une macro malveillante.
En fait, la raison est que les éditeurs d'antivirus savent très bien scanner les divers documents produits par MS Office mais ce n'est pas encore le cas des documents produits par OpenOffice alors même que leurs moteurs sont portés aussi bien sous Windows que sous Linux et même parfois sous Solaris.
Microsoft n'est pas le seul à faire pression, loin s'en faut mais je connais de valeureux gendarmes qui risquent soit de tirer la gueule, soit de faire pression à leur tour.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par jijin . Évalué à 4.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par salvaire . Évalué à 2.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par I P . Évalué à 9.
C'est possible sous OO?
On s'en fout il suffit juste de dire que ça existe. Ça fera vendre la prochaine version de l'anti virus qui les enlève.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Comme word, en fait de ce que j'en sais.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par atmaniak (site web personnel) . Évalué à 3.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ondex . Évalué à 6.
Personnellement, je m'en fout (royalement) du "système". Il me suffit de mettre le CD de ma distrib préféré dans le lecteur et en 30 minutes le problème est réglé.
Par contre, le fait que mes données utilisateurs (mon /home) soit exposées est bien plus grave. Il serait temps de revoir les positions sur la sécurité.
(je parle bien d'un poste de bureau, qui irait utiliser OOo sur un serveur ?)
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par fmaz fmaz . Évalué à 4.
Si on interdit qu'un fichier utilisateur soit executé (/home, /tmp... en noexec),
une macro malveillante a beaucoup moins de possibilités de nuisance car
elle ne peut agir que quand on l'exécute. Si tous les virus, malware et autres
spyware avaient les mêmes restrictions, on est plus obligé de refaire des
installations parce qu'il y a des bouts de trucs dans tous les fichiers systèmes,
une machine fraîchement installée ne se retrouverai pas complètement
vérolée avant même qu'on ait pu installer les mises à jour de sécurité....
Il est évident qu'on peut et qu'on devrait mieux faire mais c'est déjà beaucoup.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Vador Dark (site web personnel) . Évalué à 3.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ondex . Évalué à 2.
En plus de ça, un système de fichier versionné (CVS, SVN ou autre) rassure énormement.
[1] La vidéo est très intérressant, je la recommande :
http://rehash.xs4all.nl/wth/rawtapes/wth_client_security_is_(...)
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Là, tu parles de Windows mal utilisé vs Unix bien utilisé, non ?
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par AlphA . Évalué à 1.
pas tout à fait. Word exécute les macros dans une sandbox.
La différence est fondamentale.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Raphaël G. (site web personnel) . Évalué à 3.
Et il me semble avoir vu un "security advisory" comme quoi il étais possible d'en sortir via un bug...
Donc bon...
Il m'est d'avis que lancer un document non sur via : sudo -u testuserXYZ ooowriter fichier.odt
et bien plus sur, c'est ton /homt/testuserXYZ qui sert de chroot pour tester le script.
Perso c'est ce que je fais pour a peu près tout (sauf pour mes logiciel tournant avec wine don't j'ai rien a faire, z'ont accès qu'a ~/.wine et il se prennent un kill -9 a la fin de leur utilisation sur tout les process wine, comme ça pas de problème)
Comme qui la séparation des privilèges est vraiment la sécurité la plus sure...
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par inico (site web personnel) . Évalué à 3.
Toutes les applications web qui recontraient un fichier .exe proposaient de l'ouvrir dans winechroot.
Je ne sais pas pourquoi il n'existe plus de nos jours.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par AlphA . Évalué à 10.
je me permets de réagir à ton message. Si l'on parle bien de la même passerelle de messagerie, et j'en connais pas 25 dans les différents ministères qui bloquent le XML et analysent les fichiers office pour en retirer le code offensif, je tiens à préciser quelques points en tant que responsable technique de cette passerelle de messagerie.
* Ce n'est pas la méchante société privée qui a pris le parti de bloquer les documents XML. Nous ne faisons qu'appliquer les consignes que nous donnent ce fameux organisme de sécurité de l'état. Oui, c'est débile de bloquer XML pour le commun des mortels mais non ça ne l'est pas dans le contexte sensible de cette passerelle, chose que tu n'as pas précisé.
* Pour ton info, les pressions pour supporter les formats opendocument ont déjà commencé en vu de l'extension du périmètre de cette politique et, tiens toi bien, le méchant industriel fait parti de ceux qui poussent à l'ouverture de ce format ! la pression est actuellement sur ce fameux organisme de sécurité pour que ce dernier :
- justifie pleinement les blocages demandés mais ça c'est pas dur, cf conf de filiol au sstic cette année
- se débrouille pour imaginer une solution de détection
- en dernier recours, après analyse du risque, accepte de laisser passer ces formats
* effectivement les produits utilisés pour nettoyer les documents bureautiques marchent uniquement avec les documents MS office pour l'instant. Désolé mais c'est dans la logique du marché pour l'instant. si le ROI pour le support de format devient intéressant, la situation changera, en attendant on bloque.
* Oui, les gendarmes ralent et ce n'est pas les seuls. mes collègues qui travaillent pour eux le font avec openoffice et ralent aussi. Mais c'est comme ça.
en espèrant avoir dissipé quelques malentendus.
bonne journée
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Bref, tout ce qui est possible de faire pour continuer à bosser sans surtout être emmerdé par les pseudo mesures de sécurité... (note le second degré)
"La première sécurité est la liberté"
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par AlphA . Évalué à 4.
utilisation de bzip <- pris en charge
utilisation de plusieurs niveau de compression <- pris en charge
changement du nom en nom d'image <- on se base pas sur l'extension pour reconnaitre un format ....
utilisation de messagerie personnel sur webmail <- pas mon problème, c'est celui d'un autre indus
utilisation de transfert ftp <- pas mon problème, c'est celui d'un autre indus
faut comprendre un truc : cette messagerie (celle qui bloque les xml et provoque les ralements du monsieur au dessus) est placée en interconnexion d'un réseau *sensible* utilisé par beaucoup de non geeks donc ok, on peut raler sur le blocage de xml mais c'était une mauvaise idée de le faire sur *ce cas précis*. donc il n'y a pas de contournement à 2 francs comme on peut le faire sur un av personnel de base ni de pseudo mesure de sécurité et OpenDocument est bloqué pour une raison valable *DANS CE CAS* (j'espère avoir été assez clair).
merci de ne pas généraliser le cas général avec un cas particulier bien précis, ça évitera les réflexions à 2cts. sur les méchants industriels maqués avec MS, les vendeurs d'AV verreux, etc.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par inico (site web personnel) . Évalué à 4.
Fichier à l'interieur d'une image (champ EXIF et co) ?
Tu fais quoi si une des archives a un niveau quelconque de compression a un fichier de 17 Teraoctect ?
Et la question la plus importante, c'est quoi la raison valable ?
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par AlphA . Évalué à 5.
je n'ai pas envie d'ergoter pendant des heures donc je vais faire en sorte de mettre à fin à la discussion.
je ne cherche pas à bloquer des fichiers pour le plaisir de bloquer des fichiers,
je cherche à protéger les utilisateurs.
les 2 1ers points que tu cites nécessitent de la part du destinataire une action supplémentaire d'extraction du fichier, outils qui ne sont pas installés normalement sur les postes des utilisateurs et qui n'ont pas les droits pour le faire. Si le destinataire a installé l'outil pour extraire ces formats, il est déjà en violation de la politique SSI donc à lui d'assumer.
avant que tu ne rétorques "ouais mais si ça extrait le fichier infecté via l'exploitation d'une faille en utilisant un shellcode dans le mime type ou si un script est livré avec, tu te fais avoir, t'es vraiment trop nul, haha", je précise que tout ce qui s'apparente à du binaire (et assimilé via encodage en unicode ou autre) et tout ce ressemble de près ou de loin à un script est systématiquement bloqué.
le dernier point est un faux problème depuis un paquet d'années pour les applications d'analyse de contenus un tant soit peu sérieuse... excuse moi de dire cela assez brutalement mais le fait que tu cites cet exemple comme un problème potentiel donne, imho, une idée sur ton niveau de compètence concernant le sujet de la discussion.
avec ma dernière phrase, j'ai l'attaque personnelle, il me reste à rajouter que oui, c'est une politique de sécurité de nazi. Comme ça, j'ai aussi le godwin, ce qui va permettre de mettre fin à la discussion.
quand à la raison valable, comme tu as l'air d'être du genre super l33t en sécurité, je te laisse la deviner.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par inico (site web personnel) . Évalué à 4.
J'avais planté un serveur mail de l'armée avec mon dernier point.
Et puis si ton application veut analyser du contenue au 25iéme niveau de compression, elle n'a pas le choix, il faut qu'elle decompresse d'une façon ou d'une autre.
A moins qu'on est configuré une limite et dans ce cas, on rejette les fichiers joints bizarre.
Tu n'es pas un peu enervé ?
Passé une mauvaise journée ?
L'application n'est pas homologué ?
Personne n'ose ecrire un script pour virer les macros des fichiers qui sont pourtant dans un format connus donc manipulable ?
Un fichier word c'est du binaire à volonté et je crois pas que microsoft a donnée de la doc sur le format.
Au contraire tu vient juste de la relancer :)
Proteger des utilisateurs en leur empechant l'accés à ce qu'ils ont besoin, c'est contre-productif et a long terme ca nuit TRES fortement à la securité.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par AlphA . Évalué à 3.
me suis vénère ce matin suite au post initial complètement HS & plein de mauvaise fois sur les méchants indus véreux maqués avec les grands pontes, la débilité d'un système dans lequel j'ai mis bcp de neurones, etc,etc donc désolé, me suis vengé bétement. Là ça va mieux après un bon acharnement sur mon rameur :o)
vais essayer d'être assez clair sans trop m'épancher non plus et après fini.
donc :
* oui, les fichiers de type container (zip, office, etc) nécessitant une analyse dites récursives ont un seuil autorisé de récursion. Ce seuil a besoin d'être assez élevé en partie justement à cause des documents office (.doc -> ole -> excel -> ole -> ....) d'où la nécessité d'introduire également une limite sur le temps d'analyse et sur l'espace mémoire occupé par la version décompressé (afin d'éviter le zip de 1ko décompressé en 4 Go). si tu es tombé sur un serveur de l'armée qui s'est vautré avec ce genre de pb, shame on them...
* les odt, xml, etc sont pour l'instant bêtement bloqués car il existe une possibilité (non théorique) de détourner ce format dans un but offensif via, je crois, l'utilisation de xslt, etc. Ce que l'on ne peut se permettre dans un contexte sensible qui est celui de la plate forme de messagerie si méchante envers les gentils geeks. Le but de la passerelle n'est pas que transférer des mails et faire râler les linuxiens mais il est également d'assurer le niveau maximal de sécurité sans passer par un sas de transfert manuel (un antivirus humain en quelque sorte ... ;o) )
* le problème des macros n'en est plus trop un dans le cas de office via certains éditeurs d'av mais l'est, et de façon encore plus dangeureuse que ms office (pas de sandox) dans le cas de openoffice. Même cause, même conséquence -> on peut pas se le permettre.
* le problème est que développer un plugin de suppression de macros pour ce format coute très cher et nécessite des grosses compétences dans des domaines particuliers. dans la mesure du possible on évite les scripts perl one shot qui marchent que sur 3 fichiers de test et basta. Derrière y'a 20k users qui risquent de pas être content et de taner la chaîne de support.
J'ose même pas imaginer le coût d'un plugin d'analyse du format xml...
* De plus, l'organisme protégé par cette fameuse passerelle a homologué un format bureautique et ce format, c'est office 97 ! ben ouais, c'est con à dire mais l'état c'est pas crésus et l'argent investi dans les licenses et la formation ne peut être ignoré. Bien sur, au gré des projets, cd piratés refilés par le beau frère, etc y'a du 2k et du 2k3 qui se promènent et on fait pas les batards non plus quand un problème remonte concernant un fichier office 2003. Mais bon, c'est pas mère thérésa land non plus. Donc si le client veut le support xml & macro openoffice de façon + intelligente que le blocage actuel, ben il paye ou le fait lui même.
* concernant le débat que j'ai relancé bien malgré moi, cf ci dessus. Les utilisateurs sont sensés avoir office et leurs correspondants aussi. Ce format est reconnu comme format d'échange donc on a fait le max pour permettre ça sans diminuer le niveau de sécurité. Lorsque le format opendocument sera soit très répandu soit déclaré comme norme de communication standard, le boulot sera fait.
Il faut comprendre que les formats bloqués sont les formats "dangeureux" et uniquement lorsque l'on ne peut pas les nettoyer avec confiance.
dans 99% des cas, les documents office + pdf + image, etc ça suffit à ces utilisateurs. C'est une messagerie pro après tout. Alors bien sur la dernière blague au format exec qui affiche une nana avec les seins qui bougent sur le bureau ou le super activex à la mode qui fait des wizz dans IE passent pas mais bon, perso ça me pose pas de cas de conscience :p
en espérant avoir éclairci les interrogations et répondu aux questions.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Earered . Évalué à 2.
Si je comprends bien le schmilblik:
*l'État dispose des compétences, mais pas forcément de l'argent nécessaire pour dégager le temps nécessaire à ce développement (en engageant des assistant pour les taches demandant des compétences plus communes par exemple).
*l'éditeur ou l'État n'ont pas envie d'engager un prestataire extérieur (très/trop cher) pour faire ce développement.
Alors, est ce qu'il est possible, si l'éditeur est en croissance, de leur suggérer d'intégrer ce développement via leur processus de recrutement? Par exemple des stagiaires (futur employé de l'éditeur) du Magistère sécurité de l'ENST. Surtout qu'il me semble qu'un certain nombre de personnels de l'armée (ou futur pour les Polytechniciens) font cette formation (en formation continue, donc déjà compétent).
Pis ça devrait caresser l'éditeur dans le sens du poil de faire travailler des gens pour pas cher :p
La déclaration en norme de communication reconnue par l'État, c'est en très bonne voie, non? Il me semble que l'odt&co sont déjà des normes ISO, et qu'il y a des projets de lois à ce sujet en France et dans d'autres pays euopéens.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Space_e_man (site web personnel) . Évalué à 4.
Pour ce qui est du XML en générale, je ne suis pas sûr de bien comprendre le problème des xslt (que tu crois, d'ailleurs...) Quelqu'un peut-il confirmer ? Et n'existe-t-il aucune expertise et filtre efficace (pour sécuriser) ?
Lorsque tu parles d'un plug-in pour supprimer les macros, je crois d'abord comprendre qu'il s'agit des documents OpenDocument je fini par comprendre que tu parles des fichiers XML en générale. Hors, XML est un métat-format permettant de définir des formats de fichier structurés, avec des outils génériques permettant de manipuler ces structures. Je n'ai pas encore entendu parlé des "macro XML"... Je pense donc qu'il doit s'agir des macro contenues dans les documents OpenDocument, c'est à dire, des fichiers XML faisant référence à un descripteur bien particulier qui à un niveau supérieur présente certaines informations comme étant des macros destinées à être interprétées comme telles par les programmes qui supportent l'exécution de ces macro...
Enfin, bref, j'en retien le sentiment d'une certaine confusion entre XML et OpenDocument (basé sur XML). C'est un peut comme bloquer les fichier texte... Et quid des pages web XHTML ? bloquées aussi ?
Pour ce qui serait d'un plug-in supprimant toutes sortes de macros contenues dans tous fichier de type XML, je pense que cela est infaisable tant il existe des formats de fichier basé sur XML, présents et à venir, publiques et "privés" (DTD non disponible).
Pour ce qui serait d'un plug-in supprimant les macros des fichiers OpenDocument (basé donc sur XML mais référent à quelques DTD publiques), je pense que cela doit être facilement faisable et peut-être même que la communauté à déjà fait cela. En effet, il ne faut pas oublier les avantage d'un format ouvert..., une communauté y travail et partage... Un tel plug-in en intéressera d'ailleurs probablement plus d'un...
Je comprend et j'approuve l'application (dans certains cas) de la politique qui concise à identifier le type d'un fichier et selon possibilité, le rejette, le sécurise ou le laisse passer tel quel. Un fichier ne pouvant pas être sécurisé sera rejeté.
Il est regrettable que certains fichiers ne puissent être sécurisés du fait qu'il utilisent un format aillant pourtant ces avantages et relativement utilisés.
Le format OpenDocument n'est-il réelement pas sécurisable ? ou est-ce un manque de réactivité de quelques éditeurs / développeurs trop "autoritaires"(/puissants) du fait d'un modèle de développement fermé ?
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ragoutoutou . Évalué à 2.
Donc en bloquant le xml (en http), on peut réduit la sécurité des systèmes windows.
Je suis certain qu'une règle de sécurité interdisant l'entrée dans l'entreprise de documents xml est plus dommageable que bénéfique.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Stéphane Salès . Évalué à 4.
dommage personnellement c'est la *seule* réponse qui m'aurait intéressée.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Oh, ça, on s'en fiche, la première règle de filtrage concerne la taille des pièces jointes. Faudrait pas confondre SMTP avec FTP, non plus.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par inico (site web personnel) . Évalué à 2.
On peut parfaitement avoir un fichier .rar de quelque ko qui aprés decompression pése 17 To.
Un petit exemple: http://www.pearpc.net/files/macosx_6gb.rar
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par inico (site web personnel) . Évalué à 1.
Et ils ne savent pas dezipper ?
Et même si ils ne le savent pas, tu peux toujours ecrire un script qui supprimerait a LA-RACHE tous ce qui n'est pas du texte.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par AlphA . Évalué à 2.
Les produits utilisés savent détecter un zip renommé et l'ouvrir, analyser le contenu, etc etc mais le problème n'est pas là. Le problème vient de l'utilisation du format XML et des macros openoffice *POUR L'INSTANT*.
Donc ne pas savoir ouvrir un zip ou bloquer du texte n'a rien à voir là dedans. En plus, je vais te faire une révélation : une page html envoyée par mail et contenant un script offensif encodé en unicode est ... du texte !!! damned !
De plus, supprimer (surement pas à l'arrache) tout ce qui n'est pas du texte, c'est antiproductif. Le but est d'avoir le meilleure compromis entre les fonctionnalités et la sécurité, pas de forcer les gens à utiliser mutt & vi pour leurs correspondances.
[^] # Hors sujet
Posté par Arthur Accroc . Évalué à 3.
Bah quoi ? C'est ce que j'utilise. :-)
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ragoutoutou . Évalué à 2.
Le problème n'est pas le xml, mais la médiocrité des systèmes supposés le prendre en charge côté client.
Une passerelle mail avec une sécurité trop restrictive est généralement une preuve de manque de maîtrise de la sécurité des clients, d'un manque de maîtrise du sujet sécurité en général, et provoque surtout des problèmes de communication et de productivité, et lorsqu'une passerelle de communication devient un problème de communication, on peut parler d'échec.
Dans tous les cas, il est indispensable de permettre aux utilisateurs de récupérer des pièces jointes bloquées (pour lesquelles aucun virus n'a été détecté) de manière plus ou moins automatique (questionnaire en ligne posant des questions sur l'expéditeur et évaluant le risque avec responsabilité de l'employé engagée en cas de problèmes si celui-ci a répondu incorrectement) sous peine de nuisances sérieuses à la productivité.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Funix (site web personnel, Mastodon) . Évalué à 2.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ragoutoutou . Évalué à 5.
Totalement faux, un document openoffice, de par sa nature xml, n'est qu'un fichier texte. Je ne vois pas en quoi un antivirus aurait du mal à scanner un fichier texte pour y retrouver une macro malveillante. Si un virus frappant openoffice faisait parler de lui, les antivirus seraient rapidement mis à jour pour le détecter.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par flyer . Évalué à 6.
PS: il y a aussi des macros pyhton basicooo et beanshell mais elle ne sont pas à l'état compilé.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ChristopheK . Évalué à 9.
Les forces vives de ce Ministère et son RSSI doivent être largement plus compétents que l'O.T.A.N. Openoffice est agréé par l'O.T.A.N. et a été utilisé comme plateforme de messagerie commune entre les diverses forces publiques lors du sommet du G7 à EVIAN ! Qui est le RSSI super pointu de ce Ministère qui connait bien les failles de ODT et la supériorité des .DOC en matière de sécurité ?
C'est rassurant d'avoir de telles pointures dans notre administration !!
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Psychofox (Mastodon) . Évalué à -1.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par ChristopheK . Évalué à 2.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par herodiade . Évalué à 7.
L'ADAE préconise d'utiliser des formats interopérables (donc généralement des standards ouverts, sauf lorsque celà est en contradiction avec la priorité d'intéropérabilité / large support - ainsi mp3 est préconisé, à juste titre, au détriment de ogg qui est moins universel).
Mais l'ADAE ne préconise en aucun cas d'utiliser des LLs. Elle ne préscrit pas d'implémentation spécifique. C'est bien ce qui lui donne sa légitimité: rester neutre , vendor agnostic, pragmatiques, et centrés uniquement sur l'intéropérabilité. Irréprochable, même par nos ennemis, en somme.
C'est sur ce point que se fourvoient beaucoup de contributeurs du wiki ADAE avec des remarques comme « choisissont le format X, car bien que mal supporté dans la plupart des cas il est poussé (ou : le seul supporté) par le logiciel libre Y »: promouvoir le logiciel libre Y n'est pas la mission d'ADAE.
Cette réthorique décridibilise un peu l'ensemble du travail (qui ne mérite pas ça). Ayez plus confiance dans les LL: si l'intéropérabilité (et rien qu'elle) est privilégiée, ils sauront s'imposer ! De même: les décisions orientées seulement par l'intéret commun public suffiront à promouvoir l'utilisation du logiciel libre, inutile ici de se laisser aller au lobbying bas étage comme nos concurents, qui ne se préoccupent pas du bien commun (« tachons d'imposer la norme / le format que nous supportons le mieux pour tuer nos concurents »), pour une fois qu'un organisme d'état décide de choisir une solution pour d'autres raisons que « les logiciels auquels ont est habitués » ou «les sociétés avec lesquelles on a des partenariats ».
Si l'ADAE déroge à cette neutralité pragmatique, ils offriraient alors aux éditeurs de solutions propriétaire une occasion révée d'invalider leurs décisions comme anti-concurentielles, unfair, etc.
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par cumulus . Évalué à 1.
L'appel d'offre n'est-il pas tout simplement obligatoire ?
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
# Bof
Posté par Grumbl . Évalué à 1.
à la limite, s'ils ne parviennent pas à migrer vers des logiciels efficaces, ils ne seront que plus motivés encore pour y parvenir dans 5 ans.
[^] # Re: Bof
Posté par flyer . Évalué à 6.
PS: principe de Peter:
- http://fr.wikipedia.org/wiki/Le_principe_de_Peter
- http://perso.orange.fr/marxiens/philo/pretapen/peter.htm
En gros: les employés tentent de s'élever jusqu'à leur niveau d'incompétence maximal. C'est pour celà que l'on retrouve souvent des incompétents à des postes à responsabilités.
[^] # Re: Bof
Posté par flyer . Évalué à 5.
[^] # Re: Bof
Posté par Colin Pitrat (site web personnel) . Évalué à 1.
http://fr.wikipedia.org/wiki/Principe_de_Dilbert
[^] # Re: Bof
Posté par Grumbl . Évalué à 1.
Est-ce souhaitable ? Fait-on du LL pour ça ? J'en doute.
# Quelques précisions
Posté par yod81 . Évalué à 1.
En lisant l'annonce au JO, j'ai du mal à comprendre en quoi cet appel a "pour but de faire sauter deux verrous qui freinent l'adoption des logiciels libres".
Est-ce que quelqu'un a des infos sur le socle Icasso ou Rescom 3g ?
[^] # Re: Quelques précisions
Posté par David Allard . Évalué à 2.
Je n'ai pas d'infos sur le socle Icasso ou Rescom 3G, mais j'ai téléchargé le DCE (Dossier de Consultation des Entreprises) et je lis :
Objet du Marché
...
Fourniture de l'Icasso (Infrastructure de Courriell s'Appuyant Sur des Systèmes Ouverts)
...
Fourniture du logiciel client Associé : PABLO
....
Fourniture d'une méthode de Migration d'Exchange/Outlook à Icasso/Pablo
Donc on parle bien de l'éviction de l'architecture Courrier de chez Microsoft et donc de la mise au point d'outils qui mettent en place des choses que demandent les clients (Gestion Agenda partagé, Gestion des mails tout ça dans une seule interface). De plus ils souhaitent (Le Ministère de l'Intérieur) que ça soit multiplateforme.
Mes premières conclusions à la lecture du gros pavet.
[^] # Re: Quelques précisions
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
- Jeux : c'est le point de blocage le plus important pour les particuliers.
- Psychologiques : ils sont en train de tomber, le dénigrement (FUD) du logiciel libre est de moins en moins efficace.
- Bureautique : OpenOffice.org a débloqué la situation à 99%.
- Travail de groupe, agenda partagé intégré à la messagerie : Comme je l'ai écrit dans l'article, de nombreuses entreprises se sont organisées autour de ces outils qui font gagner beaucoup de temps. Il n'existe aucune offre libre suffisamment performante pour concurrencer Exchange. On comprend alors que cela puisse être un point de blocage.
- PDA : cela peut paraître anecdotique mais ne l'est pas, ce point a été bien développé dans les messages.
- Logiciels métiers : C'est le sommet de l'iceberg. Pour exister dans une grande structure, il faut que les autres fonctions soient en place (réseau, serveurs, messagerie, agenda partagé,...). Ces logiciels apparaîssent actuellement dans l'administration grâce en particulier aux efforts de Adullact http://adullact.org/ qui arrive à fédérer des ressources éparses et à créer une synergie nationale. Adullact agit à l'inverse des éditeurs de logiciels propriétaires qui utilisent le vieux principe : diviser pour règner.
[^] # Re: Quelques précisions
Posté par briaeros007 . Évalué à 2.
Je ne peux que plussoyer , et voudrais rajouter aussi pour les particuliers
des drivers (libre si possible) qui marche facilement .
# Déjà fait dans d'autres administrations, pour l'une par ses seuls moyens
Posté par Theo . Évalué à 1.
Dans le cas de la gendarmerie, 100 000 personnels, ils l'ont fait seuls ... il ne s'agit pas là de réamorcer la guerre des polices, juste d'être factuel ;-)
[^] # Re: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo
Posté par ChristopheK . Évalué à 3.
Coté messagerie , les fonctionalités X400 sont un peu plus complétes en ce qui concerne l'authentification , les avis de remises etc...
Il semble y avoir nécessairement des développements complémentaires à ces produits .. non ?
[^] # Re: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo
Posté par Theo . Évalué à 1.
Et ce besoin d'agendas partagés ne justifie pas le fait de devoir passer un marché pour l'ensemble de la messagerie alors que cela a déjà été fait ailleurs !
[^] # Mais vous avez quoi contre les PDA ?
Posté par Jeanuel (site web personnel) . Évalué à 2.
J'en ai un et c'est très utile. L'agenda partagé, ça ne s'emporte pas en déplacement. Autrement dit, ce n'est jamais disponible quand on en a besoin. Le PDA est toujours dans la poche. Et de retour au boulot, il met à jour/se met à jour avec l'agenda partagé.
Il y a aussi des gens qui se déplacent dans l'administration.
[^] # Re: Mais vous avez quoi contre les PDA ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo
Posté par qstone . Évalué à 4.
Je travaille pour une administration (désolé pas de noms)
Réceemment on a eu l'opportunité de proposer à nos supérieurs un remplacement de notre messagerie par un LL (on utilise actuellement Lotus Notes (client) / Domino (serveur))
Eh bien après étude, j'ai bien dû laisser tomber l'idée ! Il n'existe pas de client libre sous windows du niveau fonctionnel de Notes ou Outlook ! Et pourtant j'ai cherché...
Et pour info, on a beaucoup d'utilisateurs chez nous qui ont ces besoins "évolués", pas juste quelques "happy few" comme tu dis. Les secrétaires qui gèrent l'agenda (voire le courriel) du chef, la planif de réunion qui touche 90% des agents, assez peu de PDA c'est vrai, mais on a aussi des BlackBerry (argh) pour le haut de notre hiérarchie (rien que ça, ça tue toute possibilité de LL mais bon c'est un autre débat)...
La "meilleure" solution libre que j'ai trouvé c'est le portage d'Evolution sous Windows... Pas encore stable, avec quelques trains de retard sur la version linux (win: v2.6, lin:v2.14).
Et qu'est-ce qu'on met comme serveur avec des clients Evolution ? Réponse sur le site : Exchange ou Groupwise ! Eventuellement OpenGroupware.org, qui n'est pas vraiment plébiscité dans le monde du LL (super lourd, date un peu, etc.)
Cela dit, si quelqu'un a une solution miracle à proposer, je peux encore faire quelquechose (3000 postes en jeu !)
[^] # Re: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo
Posté par Giboyle . Évalué à 5.
- salades de synchronisation des PDA, téléphones, et des mêmes appareils avec plusieurs postes (profils itinérants ?) et/ou avec des PC perso et/ou via WiFi...
- définition fine des droits d'accès aux informations. Et quand une secrétaire émet une proposition de réunion, est-ce en son nom, sous celui de son patron (et quel patron si elle en a plusieurs ?), les réponses lui parviennent-elles ou reviennent-elles à son chef ? Son nom est-il visible ? La réponse : ça dépend des services ; on veut tout et paramétrable ! Tarte-à-la-crème !!
- usages détournés ou poussés aux limites ("tâches" Outlook utilisées pour distribuer et suivre le travail d'une équipe, demande de partage des "notes" d'un autre, formulaires, utilisation de project couplée à la messagerie (jamais vue, mais j'imagine le bazar), formulaires, etc, etc, etc...)
Logiquement, qui dit usine à gaz fonctionnelle dit problème d'ergonomie et de cohérence. Outlook en est farci d'ailleurs. Pour rire, saviez-vous que vous pouviez changer votre mot de passe Windows dans Outlook ? Si vous cherchez bien, vous trouverez, on peut ! Avez-vous déjà compté le nombre d'écrans de configuration là-dedans ? Accrochez-vous !!
Mais bon, s'il y a bien un truc que Microsoft et Lotus ont et qui n'existe pas ailleurs, ce sont ces outils intégrés de gestion globale de l'information qui circule au niveau du poste. Considérez maintenant les horreurs de reprise d'antériorité (outils propriétaires qui s'appuient sur des clients MAPI), l'absence de standards complets sur les calendrier ou les dispositifs de synchronisation, et vous obtenez un bon gros trou dans la raquette des LL sur le poste de travail en entreprise.
Et puis bien sûr, comme sur Office en général, chacun n'utilise que 10% des potentialité des logiciels. Mais dans ces 10%, tout le monde utilise une fonctionnalité "exotique" et y tient, juge et jure qu'il "ne peut pas travailler sans ça !" Comme chacun utilise une fonctionnalité exotique différente, il y a quelques freins à l'adoption de solutions alternatives...
En plus, ce sont des outils qui sont utilisés intensivement, jusqu'à 25% du temps de travail : les utilisateurs sont sensibles aux changements.
Une piste de travail instinctive :
- partir du principe que tous les clients peuvent se connecter tout le temps de partout. On y est pas tout à fait, mais on y va sûrement.
- du coup, suppression des données locales : plus de soucis de confidentialité, gestion centralisée des droits d'accès, plus de problèmes de synchronisation, etc...
- AJAX ou équivalent pour fournir des interfaces "Web" efficaces, adapter l'affichage à la taille de l'écran des clients. On peut implémenter du glisser-déplacer avec Ajax ? Pas sûr...
Il y a du boulot, c'est sûr !
[^] # Re: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo
Posté par nodens . Évalué à 1.
je ne sais pas si c'est grâce à Ajax (moi le web 2.0...), mais on peut :
http://www.roundcube.net/
[^] # Re: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
Exemples :
http://prototype-window.xilinus.com/samples.html
# culture d' *entreprise* ???
Posté par Jiba (site web personnel) . Évalué à 0.
Je ne savais pas que le "ministère de l'intérieur et de l'aménagement du territoire à Paris" était une entreprise... que je sache, tout n'est pas "entreprise" et à mon avis, c'est tant mieux !
Jiba
[^] # Re: culture d' *entreprise* ???
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: culture d' *entreprise* ???
Posté par Earered . Évalué à 2.
(genre entreprendre, tout ça) Non?
[^] # Re: culture d' *entreprise* ???
Posté par Jiba (site web personnel) . Évalué à -1.
Justement, je pense que cela est à éviter : cela va dans la direction actuelle "tout est entreprise, tout doit être gérer comme une entreprise", alors que (mais ça reste mon opinion personelle), cette vision des choses est très réductrice.
# P. Icasso ?
Posté par nodens . Évalué à 1.
Pablo ? Icasso ? P. Icasso ?
Quelqu'un sait de quoi il s'agit ? Je n'ai jamais entendu parler de ce machin... De plus, "s'appuyant sur des systèmes ouverts" c'est quand même super vague... ça peut très bien être complètement propriétaire au final. J'imagine que la rédaction d'appel d'offre incite peu à la précision dans ce cas et qu'il faut y voir une intention qui ne se mouille pas trop. Mais quand même, il m'intrigue ce P. Icasso ;)
(surtout que le système de messagerie / groupware libre avec client libre pour windows, ben je le cherche toujours...)
# Et Kolab ?
Posté par mats . Évalué à 1.
quant est-il de cette solution http://www.kolab.org/ ?
Quelqu'un a une quelconque expérience dans le domaine ?
Bye
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.