Journal Les Bureaux de demain

Posté par  .
Étiquettes : aucune
0
29
mai
2006
En regardant ce qui devrait arriver bientôt dans nos desktops en terme d'interface, aussi bien sous Windows et Linux, on se rend compte qu'il n'y a pas vraiment beaucoup de différence.
En effet les bureaux seront composés de tout un tas de widget avec une jolie interface 3D et plus ou moins d'animation dans tous les sens.
Et si cela pourrez relancer les débats "Linux est-il prêt pour les desktops ?", on se rend surtout compte qu'en terme d'ergonomie les bureaux libres ont largement rattrapé leur retard, la vrai question, aujourd'hui est : pourquoi Linux n'arrive pas à attirer les éditeurs traditionnels ?
  • # Au hasard

    Posté par  . Évalué à 10.

    la vrai question, aujourd'hui est : pourquoi Linux n'arrive pas à attirer les éditeurs traditionnels ?


    Peut etre parce qu'ils veulent pas s'embeter pour une part de marché miniscule ...
    • [^] # Re: Au hasard

      Posté par  (site web personnel) . Évalué à 10.

      Le serpent se mort la queue : tant que la pdm est minuscule ça n'intéresse pas les éditeurs mais tant que y a pas les éditeurs la pdm reste minuscule.

      Enfin bon, comme dit c'est surtout pour les jeux commerciaux que ça m'embete (un peu). Car j'ai réussi à trouver des équivalents libres a la plupart de mes anciens logiciels commerciaux que j'utilisais. Ca me dérange pas du tout que les éditeurs de softs commerciaux restent sous windows :).
  • # Pourquoi ?

    Posté par  . Évalué à 6.

    quitte a me faire foudroyer pas la communaute je tente tout de meme une reponse au "pourquoi Linux n'arrive pas à attirer les éditeurs traditionnels ?"

    Pour un desktop Linux, tout est -trop- configurable ... Du coup l'utilisateur moyen va miner son desktop apeller son support ... Et ?

    Autre chose linux c'est bien si tu sais lire !
    un utilisateur moyen deja il galere/pourri son windows et n'est pas foutu de lire l'aide ! alors les man en anglais ... Pas gagné du tout

    Pour conclure, 3-5% du marché pour Linux .... un editeur quelconque va pas se faire chier a coder correctement !



    ____________
    Humour inside
    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 10.

      Pour conclure, 3-5% du marché pour Linux .... un éditeur quelconque va pas se faire chier a coder correctement !

      Vu les résultats qu'on a avec Adobe, Nero ou plus récemment Google (des applis qui ne s'intègrent pas dans les bureaux libres), ce n'est peut être pas plus mal comme ça. Les alternatives libres à ces applications existent et marchent plutôt bien et s'il manque parfois quelques fonctionnalités, ce n'est qu'une question de temps.

      Les seules applications proprio qui n'ont pas ce problème sont les jeux, parcequ'en général on les lance en plein écran et ils n'ont pas besoin d'interagir avec le bureau.
    • [^] # Re: Pourquoi ?

      Posté par  (site web personnel) . Évalué à 10.

      un utilisateur moyen deja il galere/pourri son windows et n'est pas foutu de lire l'aide ! alors les man en anglais ... Pas gagné du tout


      traductions françaises des pages de manuel Linux assemblées par le L.D.P. : http://manpagesfr.free.fr/

      elle est pas belle la vie ? ;)
    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 4.

      Pour un desktop Linux, tout est -trop- configurable ... Du coup l'utilisateur moyen va miner son desktop apeller son support ... Et ?


      D'où l'intérêt de gnome.
      • [^] # Re: Pourquoi ?

        Posté par  (site web personnel) . Évalué à -2.

        C'est vrai que dans Kde, tout est trop configurable. C'est par pour rien qu'ubuntu a choisi Gnome...
      • [^] # Re: Pourquoi ?

        Posté par  (site web personnel) . Évalué à 10.

        Je fais pas mal de maintenance. Dans ce cadre, je propose systématiquement de remplacer les windows piratés / foirés de mes clients par un linux.
        Il me semble que le problème n'est vraiment pas l'ergonomie, ou l'apparence. La question fondamentale c'est :
        _ l'impossibilité d'identifier du premier coup le materiel compatible
        _ l'impossibilité d'installer materiel et connexion internet via le cd-rom fournis
        _ l'impossibilité / difficultée pour installer des jeux / Google earth / Déclarer les impots en ligne
        _ la peur de ne pas être compatible avec les autres
        _ l'incrédulité quand à la qualité du produit

        J'ai quelques clients qui utilisent linux. Ceux qui ne configurent rien tout seuls ou ceux qui n'avaient d'autres choix que d'acheter un nouvelle licence windows (je refuse systematiquement d'installer des logiciels pirates).

        En formation, j'utilise Linux même pour enseigner des choses basiques : notions fondamentales sur la machine, l'OS, les logiciels, lecture de l'écran, manipulation clavier/souris, gestion des fichiers.

        Le passage d'un systeme à l'autre ne pose aucun problème lorsque ces bases ne sont acquises.

        Au regard de mon experience, je dirais que c'est plus l'effet de masse et l'absence de visiblité, que l'ergonomie qui posent problème (mis à part la gestion des fichiers qui pose problème quelque soit le système).

        Ce ne sont évidament que des impressions subjectives.
        • [^] # Re: Pourquoi ?

          Posté par  . Évalué à 1.

          Quelle distrib proposes-tu à tes clients ? Comment installes-tu les maj (à distance, sur place) ?
          A ton avis quelles-sont les caractéristiques à rechercher dans une distrib pour ton cas précis ? (rapidité d'installation, adaptabilité, compatibilité matérielle, softs packagés disponibles etc.)
        • [^] # Re: Pourquoi ?

          Posté par  . Évalué à 1.

          les impôts en ligne, ca se fait très bien maintenant, à condition d'avoir une machine java. Très simplement aussi (à condition d'avoir une machine java... ).
          • [^] # Re: Pourquoi ?

            Posté par  . Évalué à 1.

            Et à condition de faire tout ça en root. Surtout le début. Et si comme moi tu commences le certificat en user, impossible d'en obtenir un deuxième pour root... J'ai dû copier mon profil firefox de user vers root pour continuer, super.
            • [^] # Re: Pourquoi ?

              Posté par  . Évalué à 2.

              euh, non, pas dans la version 2006 en tout cas. En tout cas je ne me suis pas connecté en root cette année pour faire ma déclaration d'impôts. Et comme le certificat est neuf par rapport à l'an dernier, tout va bien.
  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: La question à ta question

      Posté par  (site web personnel) . Évalué à 7.

      Les éditeurs que j’aimerai bien qu’ils soient attirés à Linux sont les éditeurs de jeu.
      C'est la seul chose qui me manque sous Linux.
      Mais en fin de compte, pour le peu que je joue .... Je suis plus souvent à trifouiller, reconfigurer, administrer ma machine, qu'a faire un quelconque jeu (sauf peut-être le Puissance 4 :))

      Je pense que si les Jeux marchaient aussi bien sous Linux que sous Windows, plus de personne passerai à Linux.
      • [^] # Re: La question à ta question

        Posté par  (site web personnel) . Évalué à 5.

        Dans ce cas le problème se résume assez facilement : Direct X
        • [^] # Re: La question à ta question

          Posté par  (site web personnel) . Évalué à 3.

          Non non, je ne parle pas de jeux porno ....

          ok je sors --6> @
        • [^] # Re: La question à ta question

          Posté par  (Mastodon) . Évalué à 8.

          Et la solution existe :
          SDL+openGL, et openAL pour le son.

          Utilisé par la majorité des jeux commerciaux existant en natif sous linux.
          Les UT par exemple.
          Même W3/WoW utilise openGL d'où son fonctionnement sans problème sous wine...

          Alternative réelle à directX qui a l'avantage d'exister sous MacOS X, *BSD, un peu n'importe quel Unix, et windows aussi.
          Pourquoi aujourd'hui se priver de toucher la totalité du marché des ordinateurs personnels avec une solution qui marche, et qui marche bien ?

          Yth.
        • [^] # Re: La question à ta question

          Posté par  . Évalué à 6.

          Ouais, enfin, le prétexte de l'API, ou de la plateforme, c'est bidon, FIFA machin sort chaque année sur 50 plateformes, quand on veut, on peut.

          T'as 50 000 jeux qui sont cross plateformes pc consoles... je pense pas que le plus long dans un jeu, c'est la spécificité D3D/OpenGL/OtherAPI , pour la 3D, le son, etc...
          • [^] # Re: La question à ta question

            Posté par  . Évalué à 1.

            Si EA a racheté Criterion, ce n'est pas juste pour le talent de ses développeurs mais surtout pour Renderware, la jolie API qui permet de faire un jeu multiplateforme facilement.

            C'est comme ça que FIFA machin peut sortir sur PC et sur les consoles à la mode du moment presque simultanément.

            BeOS le faisait il y a 20 ans !

  • # .

    Posté par  . Évalué à 10.

    >la vrai question, aujourd'hui est : pourquoi Linux n'arrive pas à attirer les éditeurs traditionnels ?

    [Disclaimer : je me fais l'avocat du diable parce que je le vaux bien]

    Je tente : le manque d'homogéneité.

    Je m'explique :

    - si tu veux faire du logiciel proprietaire sous linux, bonne chance pour la diffusion ( archi multiples, systemes de gestion de paquets hétérogenes, arborescence différente [1], systeme de menus différents [2], desktops differents [3] ). Bien entendu, dès que tu ne supportes pas un des composants possibles, tu te fais flammer ( tu t'en fous : de toute facon tu te fera flammer "pourriture propriétaire" ).

    - tu veux faire du logiciel libre ( et tu veux en vivre ). La problématique de deploiement est un tout petit peu moins compliquée : il suffit d'esperer que "la communauté" package ton appli. Et en attendant que ça se produise, tu mets une FAQ sur ton site qui explique à tes clients comment faire un tar+configure+make sous suse, redhat, debian, ubuntu, slack, mandriva, etc, etc. Forcément faudra sans doute faire un peu de support gratuitement sur les mailing list mais bon si tu es gentil, y'a certains types qui te remercieront des fois [4]. Apres il ne reste plus qu'à trouver un modele economique viable ( pense à etre milliardaire avant de commencer l'aventure, ca aide ).

    [1] oui LSB arrange les choses. C'est adopté partout ?
    [2] oui XDG arrange les choses. C'est adopté partout ?
    [3] le bonheur pour coller une icone dans la systray sous linux (gnome, kde, fluxbox etc). Sous windows, c'est la meme API depuis 1995 ( je parle pas du son , du clipboard, du toolkit etc ).
    [4] "la communauté" est "exigeante". Et malpolie des fois.
    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 9.

      archi multiples
      Contre ça, c'est sûr, y'a rien à faire : si tu a N architecture binairement incompatibles, il te faudras N binaires (quitte à tous les faire tenir dans un seul ELF, comme sous MacOS X).

      systemes de gestion de paquets hétérogenes
      C'est mieux que pas de paquets ! L'installateur loki marche partout, que je sache. Et y'en a d'autres.

      arborescence différente
      Tu installe ton truc dans /opt/MonAppli, et tout va bien.

      systeme de menus différents[...]oui XDG arrange les choses. C'est adopté partout ?
      Si parle des desktop entry, c'est supporté par KDE et Gnome, ce que l'utilisateur débutant utiliseras toujours.

      desktops differents
      Et même des thèmes de bureau différents... où va le monde ?
      Enfin, ceci dit, c'est à la distrib de s'occuper de la cohèrence de ce joyeux bourdel. kgtk et gtk-qt uniformisent le look and feel avec celui de mon bureau KDE ça me suffit bien.
      Ou alors, tu fait comme sous windows : ton propre système de skins qui ressemble à rien (cf des applis pourtant populaires, comme Firefox, winamp, microsoft truc player), ou alors tu t'en fout (comme office XP qui ne s'intègre graphiquement qu'au dernier windows).

      Bien entendu, dès que tu ne supportes pas un des composants possibles, tu te fais flamme
      Et là c'est le drame, parce que quand on te critique tu a envie de te suicider. Donc tu peut pas survivre sous GNU/Linux (ni en démocratie).

      tu t'en fous : de toute facon tu te fera flammer "pourriture propriétaire"
      Pouriture propriétaire.

      le bonheur pour coller une icone dans la systray sous linux (gnome, kde, fluxbox etc). Sous windows, c'est la meme API depuis 1995.
      Réjouit toi ! Cette merveilleuse API est disponible sous Linux ! D'ailleurs Miguel de Icaza a annoncé que le prochain Gnome serait codé en api win32 grâce à wine (ou peut-être est-ce google ?).

      je parle pas du son
      T'a raison, paske alsa ça marche bien, et qu'OSS survit pour la compatibilité.

      du clipboard

      J'avais vu une foi à quoi ressemblait l'utilisation du presse papier et du "drag&drop" en API win32, et j'ai cru à une farce.
      Enfin, je sait pas si l'API X native est mieux, mais je sait qu'elle est standardisée depuis au moins aussi longtemps. D'après FreeDesktop, Gnome et KDE sont d'accord sur la manière de l'utiliser depuis KDE3.

      du toolkit
      À mon avis doit y'avoir autant de toolkit sous windows, puisque GTK et Qt sont porté. La différence c'est que comme presque tout le monde utilise juste les deux thèmes du systèmes, il suffit de les mettre par défaut dans Qt et GTK pour l'interface ait l'air cohérente.
      Si y'avais que deux thème sous Linux, ça serait vite fait d'unifier les widgets. (l'UI c'est autre chose, mais comme sous windows les improbables standards d'IHM se font violer tout les matins...)

      Du reste si ton soft est bien, il va se faire packager, même proprio. cf la section non-free de ta distrib. Et si il se fait pas packager, tu est renvoyé à la case loki/inno setup/plopmatic3000. Comme sous win.
      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 4.

        Je suis en grande partie d'accord avec ton post mais quand tu dis :
        J'avais vu une foi à quoi ressemblait l'utilisation du presse papier et du "drag&drop" en API win32, et j'ai cru à une farce.
        Enfin, je sait pas si l'API X native est mieux, mais je sait qu'elle est standardisée depuis au moins aussi longtemps.


        J'ai quand même été très surpris lors de mon passage Win2000 -> Linux de constater les problèmes de presse papier. Encore maintenant sur ma belle dapper toute moderne quelle-est-même-pas-encore-sortie si je copie un texte dans firefox puis je ferme le navigateur et j'essaye de coller le texte dans gedit...ben ça marche pas ! Le fait de fermer firefox vide le presse papier et je perds mon texte. Si je fais la même manip au boulot avec un vieux Win2000 datant d'une demi décennie ça fonctionne impec.
        Je pense que ça vient du fait que firefox n'est pas une appli gnome et ne partage donc pas le presse papier.
        • [^] # Re: .

          Posté par  (site web personnel) . Évalué à 9.

          Hum en fait c'est une fonctionalité ^^. Si tu fait le test avec Kmail ça fera pareil.

          Le presse papier X contient une référence à la donnée contenue dans l'application et pas une copie. C'est plus économique, mais du coup, quand l'application ferme la référence est perdue.
          Si ce comportement te plaît pas, y'a des applications qui quand tu selectionne un truc en gardent une copie pour que ça reste après la fermeture de l'appli source.
          En X brut c'est xclipboard, pour KDE klipper s'en charge, et fait bien d'autres choses !

          Remarque qu'en terme purement techniques, le comportement d'X a l'air mieux vu qu'il est adaptable.
          Mais en terme d'ergonomie, ça serait mieux si on exécutait klipper par défaut sur les distribs grand public... je sait pas quelle est la tienne, si c'en est une, tu peut envisager un rapport de bug.
          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 2.

            >> je sais pas quelle est la tienne

            Ben une ubuntu dapper comme je l'ai écrit.
            Ce qui me fais dire que c'est la faute de firefox c'est que si je fais la manip inverse ça marche. Copier d'un texte dans gedit, fermeture de gedit et hop, coller dans une autre appli !
            C'est donc spécifique à firefox qui n'utilise pas le presse papier persistant de gnome.
            • [^] # Re: .

              Posté par  (site web personnel) . Évalué à 1.

              C'est surtout que gnome à choisit la méthode propre pour gerer le presse papier... Contrairement à Kde...

              Résultat, la méthode sale fonctionne, pas la méthode propre...

              J'espere déjà que pour Kde 4.0 on aura un modules kded pour la gestion du clipboard, parce que je me sers jamais du klipper...

              D'ailleurs merci de voter par la :
              https://bugs.kde.org/show_bug.cgi?id=122298
        • [^] # Re: .

          Posté par  . Évalué à 5.

          Cà, j'avais jamais remarqué car je ferme jamais une applic tant que j'ai pas collé (même sous windows)

          Par contre, je me suis aperçu qu'il y plutot 2 presses-papier. Celui que tu as en faisant ctrl+c/ctrl+v et celui que tu as en selectionnant le texte/bouton du milieu de la souris.

          Les 2 gérés simultanement.
      • [^] # Re: .

        Posté par  . Évalué à 0.

        archi multiples

        Contre ça, c'est sûr, y'a rien à faire : si tu a N architecture binairement incompatibles, il te faudras N binaires (quitte à tous les faire tenir dans un seul ELF, comme sous MacOS X).

        Si, on peut utiliser une machine virtuelle (genre java, python).
        • [^] # Re: .

          Posté par  (site web personnel) . Évalué à 2.

          A force de répéter des trucs mal exprimés cela risque d'être pris pour des généralités. Je vais donc enlever ce risque, ou "dérisquer" comme on aime le dire dans les grandes enreprises.

          Ecrits incriminés

          Contre ça, c'est sûr, y'a rien à faire : si tu a N architecture binairement incompatibles, il te faudras N binaires (quitte à tous les faire tenir dans un seul ELF, comme sous MacOS X).


          NextStep, Openstep, Gnustep, Apple ne font pas tenir N architectures dans un ELF mais dans une arborence toute bête cachée pour l'utilisateur. Pour chaque application, l'éditeur fourni un dossier ITruc.app dans lequel on trouvera les binaires que l'éditeur aura bien voulu fournir.
          Bien-sûr, Apple vends ça comme une révoltuion (universal binaries) mais c'est quelque chose qui existe depuis longtemps (voir NextStep/Openstep). La formule universal binaries bien qu'elle fasse réver est très loin de refléter la réalité technique ; technique que je trouve fort élégante au demeurant :)

          http://www.apple.com/universal/
          http://en.wikipedia.org/wiki/Universal_binary (incomplet puisqu'il ne font pas référence à NextStep)
          http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/(...)

          Par ailleurs, le conteneur ELF peut faire des miracles mais je ne crois pas qu'il puisse, en l'état, réaliser ceci.

          http://fr.wikipedia.org/wiki/Executable_and_Linking_Format
          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 2.

            Une vidéo avec S.Jobs qui pourra faire comprendre à ceux qui ne le savent pas encore à quel point OSX est basé sur l'architecture NexStep :

            http://youtube.com/watch?v=j02b8Fuz73A
          • [^] # Re: .

            Posté par  . Évalué à 3.

            <http://en.wikipedia.org/wiki/Universal_binary (incomplet puisqu'il ne font pas référence à NextStep)

            On ne dit pas : "incomplet", mais : "que je vais compléter".
            Enfin c'est ce qu'on dit par chez nous !
          • [^] # Re: .

            Posté par  . Évalué à 3.

            L'Universal Binary, ce n'est pas (comme tu sembles le sous-entendre) plusieurs binaires dans le .app, mais un unique binaire qui charge telle ou telle section en fonction de l'architecture.

            On peut d'ailleurs tout à fait avoir un "Tool" (outil ligne de commande, pas emballé dans un .app) en universal.
      • [^] # Re: .

        Posté par  . Évalué à 4.

        Je suis plus d'accord avec l'auteur original qu'a tes réponses qui ne sont pas du tout convainquante. Archi multiple, systeme hétérogène ok.

        Tout foutre dans /opt n'est pas une solution.

        Quant à la stabilité des API c'est clair que ça aide. Le copier coller sous Windows est extremement simple: SetClipboardData, GetClipboardData. Le drag and drop est plus complexe, mais rien ne vaut la stabilité des API face à une architecture "mieux" mais qui change trop souvent.

        Pareil, alsa marche ok. Mais si je l'utilise pas? si j'utilise esd. Ah non, aujourd'hui j'ai lancé que artsd. Mais pourquoi oss directement. Et puis je veux 2 sons en même temps, mais ces 2 applications demandes 2 serveurs en meme temps. La merde. UNE API de son, c'est si dûr à faire?

        Tant que tu restes dans QT ou dans gtk, ça roule, mais si tu en sorts, tu creve. Et meme dedans les API changent toujours, ce qui fait qu'un éditeur doit constament supportée énormément de version d'une application (en fonction des différentes version des lib installée).
        Mono apportera peut etre une réponse.

        Microsoft a choisi sa politique : on garde une rétrocompatibilité maximal, quitte à garder des api pourri 10 ans. Apple préfère faire de gros changement brusque à certains points stratégiques dans la vie de ses produits. Quant à linux, c'est toujours en mouvement.
        Qui est la meilleur solution?
        Pour l'utilisateur?
        Pour l'éditeur?
        Pour le logiciel en lui-même?

        Quant aux standards l'IHM sont elles rellement respectée sous Linux? Pourquoi entre différentes fenetre (d'une même application, et ça n'arrive pas que rarement), le boutons ok passe de "à gauche" du bouton Cancel à "à droite", pourquoi la doite de sélection de fichier de GTK (1, 2, ...) est elle toujours aussi pourri et des année lumières de celle de Windows, pourquoi malgré les tonnes de remarques faites à leur (géniaux) concepteurs, le projet GIMP a t il toujours une interface aussi peu conviviale...?
        Perso: je prend une application sous windows (allez, le shareware de base), je le lance je comprend rapidement comment il marche. Sous Linux, c'est "beaucoup" plus rare que je n'ai pas à lire une doc à un moment.

        PS: le top, c'est les applications libres sous Windows qui s'intègère très bien, comme notepad++ ou codeblocks, winmerge, firefox (ok, ca compte pas), filezilla, pdfcreator, winscp. Domage que très peu soient disponible sous Linux.
        • [^] # Re: .

          Posté par  (site web personnel) . Évalué à 1.

          Tout foutre dans /opt n'est pas une solution.
          C'est celle utilisée sous win : tout foutre dans program files et pourtant là, ça ne gene personne. st-ce une bonne solution ? Je n'en sais rien mais elle permet de répondre au problème et je ne crois pas que ce problème de conscience limite les éditeurs.

          Pareil, alsa marche ok. Mais si je l'utilise pas?
          Je ne vois pas le problème : chaque logiciel impose des contraintes (DX machin, lib trucmuche, carte bidule, processeur chose). Si tu n'utilises pas ALSA, beh tu n'utilises pas les softs qui imposent ALSA.

          Tant que tu restes dans QT ou dans gtk, ça roule, mais si tu en sorts, tu creve.
          L'intégration des applis windows dans le desktop LiteStep ça chlingue. Personne ne fait la remarque, pourquoi ? Parce que la solution est implicite: tu limites a un type de desktop/toolkit si tu veux pas en supporter 30. C'est comme ça que ça marche partout et ça dérange personne. Pourquoi ça serait différent sous nux ?

          Quant aux standards l'IHM sont elles rellement respectée sous Linux?
          regarde l'hétérogénéité des raccourcis au sein d'office XP (les CTRL + clic pour des types de selections différentes, F2 qui un coup permet l'édition d'un cellule, un coup lance je ne sais trop quelle fonction...) et tu verras que c'est pareil ailleurs. Et je ne te parle même pas des différences entre les applications des différents éditeurs ... Dans les applications pros que j'ai pu voir depuis que je bosse, même les menus ont des philosophies différentes (gerne le clic sur ? ouvre direct une fenetre).
          J'imagine sans problème que sous MacOS c'est le même combat (le peu que je connais ne me permet pas de me faire une idée précise).

          Il y a du boulot partout pour homogénéiser l'IHM et les APIs, ce n'est pas le monopole d'Un*x et ce n'est vraiment pas pour ça que les éditeurs d'applis 'end user' n'investissent pas : ils le font déjà pour Windows, pourquoi pas sous nux ? C'est juste qu'entre 95% et 5% de marché, le choix est vite fait et ce n'est pas en uniformisant qu'on arrangera le problème.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.