Important appel d'offres du ministère de l'intérieur

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
0
20
juin
2006
Bureautique
Parmi les appels d'offres publiés récemment au journal officiel, il en est un qui a failli passer inaperçu. Il s'agit de « Annonce n°268 publiée le 11/05/2006 dans le BOAMP n° 090 A, Dépt. 75 » intitulée « Modernisation de messageries du ministère de l'intérieur et de l'aménagement du territoire à Paris ».

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

  • # Des PDA OFFERTS dans la fonction publique ?

    Posté par . Évalué à 10.

    Les PDA sont effectivement très répandus dans les hautes sphères publiques, mais accepter ce genre de cadeaux, n'est-ce pas considéré comme de la corruption (1), déja que y a des débats houleux sur l'acceptation de chocolats de fournisseurs...

    (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 . Évalué à 1.

      Sans parler des pda téléphones portables de Microsoft pour communiquer sur les appels d'offres ... "xxx xxx euros pour un A380, reçu 5 sur 5"
    • [^] # Re: Des PDA OFFERTS dans la fonction publique ?

      Posté par (page perso) . Évalué à 9.

      Il y a une valeur limite au delà de laquelle ce n'est plus un cadeau : http://www.lentreprise.com/actu/6.11829.html mais celà ne concerne que les revenus fiscaux. Au delà, la notion de corruption ou non est appréciée par le juge si quelqu'un porte plainte. Mais qui va se plaindre ?

      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 . Évalué à 2.

        Absolument, mais je signale au passage que les règles "théoriquement" applicables aux agents publics sont bien plus strictes. A tel point que je doute quand même que les PDA qu'on trouve chez les hauts fonctionnaires soient issus de tels cadeaux. Si corruption il y a, elle doit se faire sur des objets moins voyants.
        • [^] # Re: Des PDA OFFERTS dans la fonction publique ?

          Posté par (page perso) . Évalué à 4.

          C'est assez facile de faire en sorte que le cadeau ne se voie pas. Il peut être fourni sous une forme impersonnelle mais avec une cible bien définie.
          • [^] # Re: Des PDA OFFERTS dans la fonction publique ?

            Posté par (page perso) . Évalué à 2.

            Dans le cadre du boulot pour le compte de la Défense, je gère des marchés publics, je refuse systématiquement tous ces cadeaux de la sorte, même les plus modestes, c'est une question de déontologie d'ailleurs de moins en moins de boite s'amusent à en proposer (c'était quasi systématique il y a dix ans encore voire moins). Si la boite s'amuse à me tenter dans la phase de consultation, c'est un critère de rejet !

            http://www.funix.org mettez un manchot dans votre PC

  • # L'ADAE préconise déjà d'utiliser des LLs mais...

    Posté par (page perso) . Évalué à 7.

    Ces appels d'offres sont logiques car ils découlent d'une volonté relativement ferme d'utiliser davantage de Logiciels Libres au sein de nos chères administrations. Pour autant, certains sociétés privées, cul et chemise avec certains de nos dirigeants, poursuivent un but très éloigné de l'intérêt commun.
    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 . Évalué à 4.

      ... les gendarmes qui bossent sur internet preferent linux pour remonter les sites dynamiques sans s'emmerder outre-mesure. :)
    • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

      Posté par . Évalué à 2.

      une macro malveillante
      C'est possible sous OO? Parce qu'avec PerlTeX le mode sandebox est activé par défaut ...
      • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

        Posté par . É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 (page perso) . Évalué à 3.

        OpenOffice.org te demande confirmation avant d'executer une macro, mais après, la macro peut à peu près tout faire sur ta machine (cf. dicooo qui télécharge et installe des dictionnaires comme un grand).

        Comme word, en fait de ce que j'en sais.
        • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

          Posté par (page perso) . Évalué à 3.

          Dans la limite des droits correspondant a ton utilisateur. Et mine de rien, une telle "limitation", ce n'est pas rien !
          • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

            Posté par . Évalué à 6.

            Qu'y a t-il de plus grave ?

            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 . Évalué à 4.

              Ce que tu dis est évident mais l'ancienne vision continue à être pertinente.

              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 (page perso) . Évalué à 3.

              Il est possible d'avoir deux comptes utilisateurs. Un pour ce qui concerne internet(E-mail, lecture de documents en tout genre venu de partout), l'autre pour tout ce qui est privée et de confiance(documents boulots, photo de famille, ...). Il est possible de se protéger en se basant sur les droits, qui ne sont pas forcément là que pour protéger le système.
          • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

            Posté par (page perso) . Évalué à 3.

            C'est quoi le rapport avec OpenOffice.org Vs Word ?

            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 . Évalué à 1.

          > Comme word, en fait de ce que j'en sais.

          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 (page perso) . Évalué à 3.

            Pas depuis longtemps si mes souvenir sont bon...

            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 (page perso) . Évalué à 3.

              Pour wine, a une époque il existait un script fournis avec le paquet debian: winechroot.
              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 . Évalué à 10.

      Bonjour,

      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 . Évalué à 4.

        C'est pas grave, j'imagine que les utilisateurs emmerdés font tout pour que cela marche : zip avec mot de passe, utilisation de bzip, utilisation de plusieurs niveau de compression, changement du nom en nom d'image, utilisation de messagerie personnel sur webmail, utilisation de transfert ftp, ...

        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 . Évalué à 4.

          zip avec mot de passe <- bloqué

          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 (page perso) . Évalué à 4.

            Page html avec une partie du zip en commentaire et le reste dans une autre balise ?
            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 . Évalué à 5.

              bon,
              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 (page perso) . Évalué à 4.

                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.


                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.



                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.

                Tu n'es pas un peu enervé ?
                Passé une mauvaise journée ?


                quand à la raison valable, comme tu as l'air d'être du genre super l33t en sécurité, je te laisse la deviner.


                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.


                bon,
                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.

                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 . Évalué à 3.

                  alors, tout d'abord mes excuses pour le ton limite violent.
                  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 . Évalué à 2.

                    D'abords, merci pour ces infos, c'est très sympa de votre part!


                    * 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...


                    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



                    * 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.


                    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 (page perso) . Évalué à 4.

                    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.

                    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 . Évalué à 2.

                      ce qui est sûr, c'est que si il faut bloquer le xml à tous les niveaux (http et mail), on se retrouve sous windows dans une situation étrange où certains outils de sécurité comme mbsa/sms/wus ou hfnetchk ne peuvent plus récupérer leurs mises à jour, ce qui empèche de mettre à jour correctement les postes de travail et serveurs windows...
                      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 . Évalué à 4.

                quand à la raison valable, comme tu as l'air d'être du genre super l33t en sécurité, je te laisse la deviner.
                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 (page perso) . Évalué à 1.

              Tu fais quoi si une des archives a un niveau quelconque de compression a un fichier de 17 Teraoctect ?


              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 (page perso) . Évalué à 1.

        Tes antivirus ne savent pas detecter qu'un fichier est en faite une archive zip renommé ?
        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 . Évalué à 2.

          je vois pas le rapport.

          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 . Évalué à 3.

            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.

            Bah quoi ? C'est ce que j'utilise. :-)

            ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

      • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

        Posté par . Évalué à 2.

        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é.


        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 (page perso) . Évalué à 2.

        Au final quand le système est idiot, on le contourne, je bosse pour la Défense où les mails avec des pièces open office sont considérés comme virus et donc rejetés, du coup on utilise notre boite email perso et on transfère par clé usb au mépris de toutes les règles SSI, mais bon il faut bien bosser.

        http://www.funix.org mettez un manchot dans votre PC

    • [^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...

      Posté par . Évalué à 5.

      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.


      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 . Évalué à 6.

        Un fichier OpenDocument est une archive ZIP qui contient plusieurs document XML et éventuellement des marcos java compilées. L'un dans l'autre les éditeurs d'antivirus savent déziper, lire du XML et vérifier des .jar...

        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 . Évalué à 9.

      "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."

      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 . Évalué à 7.

      L'ADAE préconise déjà d'utiliser des LLs

      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 . Évalué à 1.

      Ces appels d'offres sont logiques car ils découlent d'une volonté relativement ferme d'utiliser davantage de Logiciels Libres au sein de nos chères administrations.


      L'appel d'offre n'est-il pas tout simplement obligatoire ?
  • # Bof

    Posté par . Évalué à 1.

    Je trouverais quand même remarquablement jouissif que se révèle à l'occasion d'une migration difficile le coût induit par l'emploi par les haut fonctionnaires de ces "cadeaux d'entreprise".

    à 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 . Évalué à 6.

      Ce que je trouve dingue c'est que 3 glandus (probablement issu du principe de Peter) qui veulent faire joujou avec leurs cadeaux vont faire passer en priorité leurs amusement devant des choses essentielles. Il faut dire que ce n'est rien d'autre que de l'amusement ces PDAs offerts. C'est juste pour satisfaire leurs caprices. Les économies du contribuables, la pérénité du système, l'indépendance aux fournisseurs passeront après.

      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 . Évalué à 5.

        Je précise que le principe de Peter c'est de l'humour avec un fond de vérité.
      • [^] # Re: Bof

        Posté par . Évalué à 1.

        Ce qui implique notamment que si cette migration réussit, lesdits glandus seront confortés dans leurs fonctions, prérogatives et revenus.

        Est-ce souhaitable ? Fait-on du LL pour ça ? J'en doute.
  • # Quelques précisions

    Posté par . Évalué à 1.

    Bonjour,

    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 . Évalué à 2.

      Bonjour,

      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 (page perso) . Évalué à 5.

      Il y a des freins au changement de plusieurs natures :

      - 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 . Évalué à 2.

        - Jeux : c'est le point de blocage le plus important pour les particuliers.
        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 . Évalué à 1.

    Deux autres administrations ont déjà fait ce travail au moins : le ministère de l'équipement et la gendarmerie. Dans les deux cas, il s'agit de serveurs de messagerie sous Cyrus IMAP, de MTA Postfix et de client Thunderbird.

    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 . Évalué à 3.

      Oui mais là , on ne parle pas que de messagerie mais surtout aussi d'agendas partagés et de synchro PDA ...
      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 . Évalué à 1.

        Autant je comprends le besoin d'agendas partagés, autant la synchronisation des PDA, c'est un besoin d'"happy few". Combien y-a-til d'agents du ministère de l'intérieur qui possèdent un PDA, si j'ose dire, de service ?

        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 (page perso) . Évalué à 2.

          Vous avez quoi contre les PDA ?
          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: Déjà fait dans d'autres administrations, pour l'une par ses seuls mo

          Posté par . Évalué à 4.

          Mouaiff...

          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 . Évalué à 5.

            Tout à fait d'accord, et je souligne que les problématiques fonctionnelles sont très très très toufues :
            - 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 !
  • # culture d' *entreprise* ???

    Posté par (page perso) . Évalué à 0.

    > "Le but est d'offrir au moins les mêmes fonctionnalités car elles se sont souvent intégrées à la culture d'entreprise."

    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 (page perso) . Évalué à 2.

      J'ai écrit "culture d'entreprise" car je ne sais pas comment on dit dans l'administration. Mais dans les deux cas, quand on change brutalement la façon de travailler, ça coûte très cher en temps perdu.
      • [^] # Re: culture d' *entreprise* ???

        Posté par . Évalué à 2.

        et en même temps, on peut considérer qu'une entreprise n'est pas forcément une association de biens et de personnes à but lucratif.
        (genre entreprendre, tout ça) Non?
        • [^] # Re: culture d' *entreprise* ???

          Posté par (page perso) . Évalué à -1.

          > et en même temps, on peut considérer qu'une entreprise n'est pas forcément une association de biens et de personnes à but lucratif.

          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 . Évalué à 1.


    Caractéristiques principales : la présente consultation a pour objet le renouvellement du système de messagerie de commandement, rescom ng par la solution RESCOM 3g et le remplacement du couple Ms-Outlook / Ms-Exchange 5.5 par l'infrastructure de messagerie Icasso (Infrastructure de Courriel s'appuyant sur des systèmes ouverts) et le client associé Pablo (Programme d'accès aux boîtes aux lettres Picasso).


    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 . Évalué à 1.

    Salut,
    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.