TImaniac a écrit 6420 commentaires

Quelles sont ces fameuses fonctionnalités indispensables?
Indispensables au sens rétro-compatibilité. Bref, c'est pas compliqué, tu prends toutes les fonctionnalités de l'OpenXML qui sont explicitement là par soucis de compatibilité et qui ne sont pas dans l'ODF, ca te fait une tonne d'exemple. Exemple plus récent de fonctionnalité : les DRM.

Si ton logiciel est capable d'ouvrir ton ancien format il doit y avoir moyen de le convertir dans un format propre sans conserver les casseroles du vieux format.
Si tu codais un peu et que tu faisais mumuse avec des formats de fichier, y'a longtemps que tu te serais aperçu que la plupart des convertions de formats se fait "dans la douleur" avec une perte souvent non négligeable d'informations. La plupart des applis marchent sur ce mode : un format "natif" qui contient toutes les informations, et de nombreux formats supportés en "import" ou "export", autrement dis avec pertes. L'ODF peut être supporté par MS Office à travers un mécanisme d'import/export, mais il ne peut nullement être utilisé en natif sans passer par des hacks à 2 balles (simuler des fonctionnalités non présentent dans le format en utilisant une autre fonctionnalité, sans aucune garantie d'interprétation correcte par une application tierce).

Super. Si je reçois un document provenant d'Office et utilisant ces "hacks" comme tu le dis toi-même, je pourrais pas l'ouvrir. Génial!
Bah oui, c'est un choix hein, et c'est celui de l'ODF : on fait table rase du passé (celui de MS Office en tout cas) pour avoir un truc clean mais avec une rétro-compatibilité douteuse, soit on implémente tous les vieux hacks. Y'a pas de miracle. Mais c'est vraiment de la mauvaise fois que de dire qu'un format visant à décrire de manière formelle tous ces vieux hacks est "inutile".

Apparemment ce boulot a été plutôt rapide, surtout en comparaison de la taille du document (cf. les liens donnés plus haut). Le processus pour l'ODF a pris beaucoup plus de temps avec plus d'acteurs.
Le nombre d'acteurs est tout sauf significatif. A la limite, plus le nombre d'acteurs est important, plus la procédure est "lourde" et potentiellement longue. Enfin ca démontre rien du tout.

D'autre part pour un standard ISO ne pas être conforme avec d'autres standards ISO me semble assez... bizarre.
Mais l'ISO s'en cogne royalement ! C'est pas le W3C qui vise à créer des standards "universels".

Inutile de le proposer à l'ISO.
...
Dans ce cas autant ne rien spécifier du tout à l'ISO. L'ISO est une certification, un gage de qualité quand à la forme des spécifications et leur accessibilité, l'ISO ne discute pas du fond, de la pertience ou autre, c'est pas son rôle.

Ne me dis pas la compatibilité avec les vieilles versions d'Office, pour moi c'est un argument complètement bidon.
C'est pas bidon, c'est un objectif comme un autre. Il peut ne pas t'intéresser, mais il en intéressera sûrement beaucoup.

Sans même avoir les spécification MS OpenOffice arrive bien à ouvrir la plupart des documents Office et les convertir vers de l'ODF.
t'as des pertes d'informations. Même si c'est globalement acceptable dans un processus de migration, MS peut pas dire à ses clients : "oué alors maintenant c'est l'ODF en natif, vous migrez tout, tant pis si y'a des macro qui marchent plus, tant pis si y'a des trucs qui marchent plus, tant pis si vous perdez des fonctionnalités".

Dois-je rapeller qu'un standard doit être intéropérable et donc implémentable par n'importe quel acteur et sans avantager l'un par rapport à l'autre.
Bah dans ce cas l'ODF aurait dû être conçu "from scratch", et avec le principal acteur du marché, MS. Visiblement les objectifs de chacun étaient différent, l'ODF a été conçu comme un concurrent à MS Office basé sur le format d'une suite concurrente : OOo.
De plus MS ne peut pas se permettre de ne pas maîtriser l'évolution de son format : du format dépend l'ensemble des fonctionnalités d'Office, qui serait assez con pour soumettre les évolutions de son application commerciale aux bons vouloir d'un comité régis par un grand nombre de concurrent ?

Et bien si, l'ISO peut très refuser une proposition parcequ'elle ne répond pas au besoin, parcequ'elle est mauvaise ou qu'elle fait double emploi.
Bah bizzarement personne ne semble supposer que l'ISO va le refuser, comme quoi elle la norme est pas si mauvaise, elle répond à un besoin, et qui justement est différent du besoin existant, assurant ainsi le fait qu'elle ne fait pas double emploi. CQFD.

. ODF est maintenant normalisé à l'ISO et on ne voit pas l'intérêt d'un format concurrent.
Sachant que l'ODF ne répond pertinement pas aux attentes de 90% du parc des suites Office déployés, cet argument pu la mauvaise foi à plein nez. Le fait que MS Office est des fonctionnalités non supportés dans l'ODF alors que cette suite est la plus répendue montre également clairement que l'ODF ne suffit pas, et qu'il y a donc un intérêt à avoir un autre format.
De plus le fait d'avoir une certification ISO ne proclame pas l'universalité d'un format, elle certifie juste ses spécifications. Il y a de nombreux exemples de formats concurrents à l'ISO.

Elle est trop longue: plusieurs milliers de pages là où ODF en demande quelques centaines
C'est juste que le contenu n'est pas le même. Et ca justifie justement pleinement l'existance des 2 formats : le format OpenXML joue la carte de la rétro-compatibilité en détaillant toutes les fonctionnalités "historique" de MS Office. L'ODF a préféré ne pas s'embarasser avec ca pour avoir quelque chose de plus "simple" et "propre", c'est un choix qui se défend, mais il écarte tout de suite l'ODF du titre de "format universel".

. Cela rend la norme difficile à implémenter
Argument bidon : on peut toujours développer un sous-ensemble de la norme sans tous les "hacks" spécifiques aux vieilles versions d'Office si ca nous intéresse pas. Les annonces de Novell (OOo), Corel (WordPerfect) et même IBM (à travers Lotus) de supporter ce nouveau format relativement rapidement montre également qu'il n'y a rien d'insurmontable.

et c'est beaucoup trop pour que la norme puisse être revue dans le processus d'adhésion rapide (fastrack) à l'ISO.
Oui enfin c'est pas comme si y'avait pas déjà un gros boulot fait en amont à l'ECMA...

Par exemple au lieu d'utiliser MathML pour coder les expressions mathématiques, MS réinvente un autre format complètement différent. C'est stupide et complique encore l'implémentation.
MS ne réinvente rien, ils se basent encore une fois sur leur existant, existant qui est au passage antérieur au format MathML...

Certaines parties sont présentes pour assurer la "compatibilité" avec de vieux formats Microsoft le tout en propageant de vieux bugs (sur les dates notamment). D'une part j'ai du mal à voir l'intérêt,
Tu vois pas l'intérêt de la compatibilité avec la suite MS Office ? Toi aussi tu fais dans la mauvaise foi on dirait...

D'une part j'ai du mal à voir l'intérêt, d'autre part le document fait référence à des spécifs MS qui ne sont pas fournies
Donne un exemple.

En conclusion le format OpenXML est peut-être bien (enfin j'ai quelques doute tout de même) mais il n'a rien à faire à l'ISO ou alors il devra être profondément remanié.
Le but de l'ISO est de normaliser un ensemble de spécifications. Tout ce que vous reprochez à l'OpenXML, c'est de ne pas répondre aux même objectifs que l'ODF, et donc de déclarer que son intérêt est nul. l'ISO n'est pas là pour arbitrer ce genre de truc.

Celle la elle est MAGNIFIQUE! En gros ce que tu es en train de dire c'est que l'ODF c'est tellement merdique que MS ne pouvait pas decemment l'utilise
Non, ce que je dis juste, c'est que l'OpenXML et l'ODF ne répondent pas aux mêmes besoins : l'ODF se veut un format "clean", l'OpenXML se veut un format "rétro-compatible". C'est pourquoi MS a quitté le comité de standardisation de l'ODF : ca répondait pas à ses besoins. C'était quoi le besoin principal de MS ? Toujours le même : assurer un maximum de compatibilité avec le parc existant.
Je dis pas qu'un format est mieux que l'autre, mais juste que la création des 2 formats étaient inéluctables.

Moi je dirais plutot que opendocument est indispensable, sans opendocument le format des suite office serait toujours un binaire tout pourri sans specification etc.
C'est fort probable. OpenOffice1 et son format XML a poussé MS a pondre le format XML de Office 2003 (pas libre toussa). Ce dernier a poussé IBM & Co a répliqué en ajoutant une valeure ajoutée : le précieux label ISO. Sortie de l'ODF. Ce qui a provoqué à son tour MS à réagir en sortant l'OpenXML.
Comme quoi l'émulation a du bon, et ca serait idiot de la supprimer, surtout que les 2 formats peuvent cohabiter.

lier a cette entreprise pour la perennite des informations est excessivement dangereux!
On lie ses données à un format à un instant X. Aujourd'hui si je décide d'utiliser le format OpenXML, je suis assuré dans 10 ans de pouvoir toujours les lire (indépendemment des choix futurs de MS), ayant les spécifications complètent du format, le format étant humainement lisible, et un minimum d'outils assurant sa lecture/convertion vers autre chose existe/existerons.

Tu te moques de qui la?
De personne. Suffit de lire les spécifs pour trouver tout un tas d'adaptation pour ces différentes suites. Novell s'amuse pas à participer au comité de normalisation puis à s'investir dans son implémentation dans OpenOffice.org "pour le fun".
Pareil pour WordPerfect, lisez les specs bon sang. D'ailleur le support d'OpenXML dans WordPerfect est également annoncé pour le milieu de l'année. Comme quoi il doit être dûr à implémenter ce standard.

MS a claque la porte lors des discussion pour la creation de Opendocument en pretextant que cela ne correspondait pas a ce qu'ils voulait faire.
Ce qui est sûr, c'est que IBM & Co avait surtout pas envie de répondre aux besoins de MS, leur objectif n'est pas de créer un standard universel (c'est complètement illusoire), mais de créer un concurrent et le mettre en avant face à Microsoft et sa suite MS Office. D'ailleur c'est bien connu, l'ODF est la solution miracle et facilement implémentable dans MS Office c'est ça ?

qui lui etait reelement ouvert pas un comite interne a MS a qui il fallait dire oui oui Ms billou votre format est absolument fabuleux.
C'est pour ca qu'au début lors du draft initial de l'OpenXML, les critiques c'était "oué c'est naz c'est super court par rapport à l'ODF" et après 8 mois de travail du comité de normalisation les critiques étaient "oué c'est beaucoup trop riche comme norme, inutilisable".
C'est qu'ils ont tous fait "oui oui" sans proposer la moindre amélioration n'est ce pas ?

Encore une fois, c'est pas compliqué de lire les drafts et le document final pour constater l'énorme travail effectué par le comité de normalisation de l'ECMA. Ah oui et arrêtez de parler de "standard", genre comme si un format de document de travail de suite Office pouvait être unique et commun à toutes les suites , comme si elles allaient avoir toutes les mêmes fonctionnalités sans plus aucune émulation et véritable concurrence.

L'OpenXML est indispensable et pas possible à remplacer par l'ODF : il propose un support "lisible", documenté et librement implémentable des formats des nombreuses versions de la suite MS Office, et ca c'est bien le plus important : la pérénité des informations peut être assurée.

MSOffice utilisera XPS par défaut.
Faux. Par défaut MS Office ne supporte pas l'XPS, il faut télécharger un plugin sur internet, tout comme il est possible par le même biais de télécharger un plugin pour le support PDF.
MS voulait proposer le support des 2 formats en standard dans MS Office, mais visiblement Adobe n'était pas d'accord : entre favoriser leur techno pour qu'elle devienne un standard et assurer leur business (vendre des outils de productions de PDF), Adobe a choisi.

euh rappelle moi Novell c'est bien la boite qui fait du linux et qui vient d'etre "sponsorise" par une autre boite informatique du nom de Microsoft?
C'est la boîte qui a trouvé utile de travailler avec MS pour rendre leurs produits interopérables, donc il est assez logique que Novell participe au comité de normalisation de l'OpenXML.

et une vrai discussion de la part de differents acteurs du marche des suites office pour faire un format qui soit vraiment interoperable c'est pas tout a fait la meme chose.
Certes, mais le processus était pleinement ouvert, et tous ceux qui le voulait pouvait s'y joindre.

De plus l'OpenXML a quand même été pensé en vue d'être implémenté dans des suites comme OpenOffice.org ou WordPerfect. Si Apple était là, on peut aussi parier sur un support dans leur suite bureautique. Il manque quoi comme principaux acteurs ?

L'interopérabilité dans ce domaine est illusoire, on peut juste s'attendre à une "certaine" compatibilité, et ni l'OpenXML ni l'ODF ne sont des solutions miracles, juste des solutions autorisant les transitions/migrations sans trop de douleurs.

Format OpenXML qui a été conçu en collaboration étroite par Microsoft et l'ensemble des participants au comité de normalisation de l'ECMA, c'est à dire des acteurs comme Apple et autre Novell. Même si c'est basé sur une proposition de MS "interne", le résultat final est un travail d'équipe.

Avant de critiquer, faudrait commencer par respecter soit même quelques règles élémentaires, je cite dans ton extrait :
"Ce message est une correspondance privée."
"Il n'a pas vocation à être diffusé à des tiers."

Ok, sur le fond c'est vraiment un appel à propagande ou au troll suivant la définition qu'on préfère, mais jusqu'à preuve du contraire, il n'est pas interdit de troller et de parler politique dans les forums, alors que révéler une correspondance privée sans l'accord de son auteur, ca c'est vraiment pas malin.

Non seulement c'est basé sur un modèle objet, mais c'est aussi basé sur les plateformes à bytecode : afin d'exploiter la syntaxe native du langage (Java ou C#) pour les requêtes (et ainsi profiter de toutes les vérifications de typages et le support des IDE), le moteur db4o "compile" le bytecode à la volée. C'est à mon avis beaucoup plus difficilement envisageable dans des environnements qui produisent du code natif sans autre méta-données (type C++).

Sinon tu as pensé à tester db4o ? Ok, c'est pas vraiment SQL, mais justement, ca serait pertinent de voir si y'a des grosses différences de performance, le but étant bien entendu de stocker le même genre d'information.

ce qui me surprend c'est ta réaction face à ce qui n'est qu'un fichier .ini : "vraiment un truc de geek qui veut se la péter". j'ai l'impression que s'il y avait juste un fichier de configuration à éditer à la main et pas cette interface certes sommaire mais qui t'évite d'avoir à redémarrer, tu serais beaucoup plus heureux. là, je me gratte quand même un peu la tête...
Bof, même un fichier ini ne justifie pas l'absence de documentation...
Nan ce qui m'énerve, c'est qu'à chaque fois qu'on critique firefox, on se prend des réponses du style : "C'est comme pour tout, quand on cherche pas on ne peut pas trouver." (voir plus haut). Ou mieux, quand tu critiques le principal défaut de firefox, qui est de gérer la RAM d'une manière plus que douteuse, le firefan (pas mal ca tiens comme appelation :) ) te dis "non non, dans about:config tu peux modifier la façon dont il gère le cache blabla". Voilà, on en arrive à sortir des features pourtant "vitales" pour le kidam (bouffer moins de RAM) qui ne sont accessibles qu'à travers cette page alacon. Ca me gonfle passablement :)

houlà, moi je suis sous epiphany, et j'ai un bouton sur chaque onglet depuis un baille :)
Mais ayant été longtemps un utilisateur de firefox, cette page "caché" about:config m'a toujours gonflé : une tonne de paramètres, sans aucune doc (je demande pas grand chose : des enum à la place des entiers, et une mini-description), on se croirait dans la base de registre de Windows.
Y'a pas que madame michu qui a le droit à de la doc, même les hackers ont un minimum de bon sens en commentant leur code. Là le about:config c'est vraiment un truc de geek qui veut se la péter en pouvant rabattre le caquet au débutant qui n'a pas trouvé le page-super-connue qui contient l'option archi-connue.

Oué mais moi je prône une ergonomie et une accessibilité même pour le geek de base. C'est pas parcque je m'y connais que j'ai envie de passer des heures à chercher des conneries, je vois pas pourquoi y'aurait que madame Michu qui aurait le droit d'avoir un truc facilement "utilisable".

Oué enfin même quand on cherche, à moins d'être un geek avec un background en programmation, je vois vraiment pas comment madame Michu peut trouver cette option... Même un geek qui s'y connait est obligé de tatonner avec une valeur entière jusqu'à obtenir l'effet désiré...
Ok je comprend que about:confi reste du domaine de la configuration "super avancée" mais on a inventé les types énumérés et les "dropdown" pour sélectionner une option textuelle bien plus parlante. (Ah oui et on a aussi inventé ce qu'on appelle une "description").

Si tu regardes le tableau 5 du papier, tu verras que les solutions "basées sur des VM" ont besoin de plus de "proc" que strigi
Oué enfin faudrait comparer ce qui est comparable : Tracker, Beagle et JIndex ont des résultats comparables en terme de requête, Strigi semble "oublier" pas mal de résultat... Alors que bon c'est quand même le but premier de chercher. Alors forcement si son algo d'indexation est rapide mais pourri...

Donc pour résumer, Beagle utilise plus de trois fois plus de CPU que Strigi, et donc ce que tu dis est inexact.
Si je compare par rapport à ce qui es comparable, c'est à dire avec Tracker qui retourne grosso modo des résultats très similaire (et donc une même qualité d'indexation), non ce que je dis n'est pas inexact.

Tu sais où son tes documents, c'est bien, mais ces moteurs d'indexation n'indexent pas seulement le nom du fichier, mais aussi leur contenu, et pas seulement les fichiers, également tes mails, tes logs jabber, tes contacts, tes paquets debian et j'en passe.
Mais bien sûr, si je te demande de me retrouver la conversation où on a parlé de trucbidulechouette, tu vas me la retrouver toute seule comme un grand très rapidement, n'est-ce pas ?

si j'ai un truc en background qui me mange une grosse partie de ma memoire cela ralenti tout mon traitement et ca me fait pas rire du tout.
Bah si à la place t'as un un truc en background qui à la place de bouffer de la mémoire bouffe du proc, je te garantie que ca ne va pas arranger ton temps de traitement :)
Plus sérieusement, y'a pas de mystère, indexer un grand nombre de contenu, ca consomme des ressources (mémoire de "travaille", mémoire sur disque, ressources de calcul), on a là plusieurs stratégies, elles ont toutes des avantages et des inconvénients, mais je ne suis pas sûr qu'il y en ai une de forcement meilleure : le tout est de savoir adapter cette consommation. Moi je t'ai montré que dans des environnements "conçus pour", la consommation mémoire qui bien que paraissant importante peut être paradoxalement beaucoup plus flexible en fonction des ressources de la machine. C'est pareil pour la consommation processeur : on peut bouffer beaucoup de proc, mais en étalant intelligement dans le temps cette consommation (comme il a été dit dans un commentaire juste au dessus) on peut également rendre cette consommation relativement transparente.
Bref, je pense qu'en l'état actuelle on a que des embrayons de solutions dont aucune n'est parfaite et vraiment mature, les algos et stratégies sont largement peaufinables.
Moi ce que je voulais juste faire remarquer, c'est que :
- les solutions basés sur des VM avec gestion automatique de la mémoire bouffe "naturellement" plus de mémoire, mais savent visiblement bien l'exploiter : ils n'ont pas besoin d'autant de proc que les autres solutions pour faire le même taf.
- les solutions "pure et dur" ala C/C++ qui ont une gestion moins flexible de la mémoire (en tout cas beaucoup plus manuelle et lourde si on voulait simuler le même type de comportement) font naturellement le choix d'une consommation mémoire largment moindre, mais qui est pénalisé par une plus grande consommation de CPU, ce qui là encore peut être facilement contourner par une gestion "intelligente" des ressources processeur en fonction du contexte d'utilisation de la machine.

Tu confonds un peu tout, utilisation mémoire (RAM) et taille de l'index. Dans le document, la conclusion est que Mono et Java bouffe plus de mémoire que les autres (ce qui a des explications bien sûr), mais par contre ils ont des fichiers d'index plus petits.
Si Beagle est JIndex prennent plus de mémoire c'est pour 2 raisons (page 12) :
- Ils utilisent beaucoup moins de processeur que les autres : visiblement ils favorisent l'utilisation mémoire et donc probablement le cache plutôt que de faire faire beaucoup d'opération par le CPU.
- Intrinséquement Mono et Java gèrent eux même la mémoire, s'il y a de la mémoire dispo, ben le runtime l'utilise et ne la libère pas forcement dès qu'elle n'est plus utilisée : elle peut être recyclée (gain de temps à l'allocation) ou bien libéré en temps voulu (genre l'utilisation mémoire arrive à saturation).

Si c'est bien fait, un programme écrit en Mono Java peut se permettre d'utiliser un cache "automatique" basé sur le garbage collector (gestionnaire mémoire) : un objet est marqué comme "peut être recyclé" : la mémoire est utilisé (même si c'était pas nécessaire) comme un cache : gain de temps, moins de calcul CPU et/ou moins d'accès disque. Si un besoin mémoire se fait sentir à l'extérieur, le cache est "purgé", les objets sont donc nécessairement reconstruit lorsque le runtime tente d'y accéder, avec utilisation de CPU/Accès disque, mais moins de consommation mémoire (le cache est vidé).

Ce mécanisme n'est pas proposé "par défaut" en C/C++, c'est pourquoi les autres moteurs d'indexations font largement gaffe à l'utilisation mémoire, mais cela se traduit visiblement par une consommation CPU plus poussée, et sans doute une base de données plus grosses (qui contient probablement plus de tables d'index pour en fait reproduire la vitesse d'accès proposé par un cache mémoire).

Arrêtez moi si je dis des conneries :)

Pour ce qui est de l'extraction de données, ce sont souvent les mêmes outils qui sont utilisés : en gros un programme externe est appelé (genre pdf2txt) avec objectif de récupérer le texte sur la sortie standard.

Donc Fluendo aurait très bien pu distribuer les codecs Mpeg-2 et Mpeg-4 libre...
MPEG-4 oui, MPEG-2 non. Il me semble qu'il y a des royalties sur chaque logiciel déployé exploitant le format MPEG-2, ce qui explique que l'on ne trouve aucune implémentation "légale et gratuite" de MPEG-2.

t'as trouvé la réponse, tu fork, tu fais des threads :)
A partir du moment où tu parrallélises un maximum ton code, tu permet à l'OS de répartir "intelligement" les tâches entre les coeurs/processeurs, et donc tu autorises une utilisation plus optimale des ressources de calcul.

Et ça n'est pas près de disparaitre. Zont vraiment rien d'autre à foutre les journaleux en ce moment. On [1] se fait tirer dessus de tous les côtés, et ils nous parlent d'une erreur de vocabulaire. Lamentable.
C'est pas du journalisme, c'est de la news people, un espèce de truc racolleur qui attire les lecteurs (et donc les sources de revenus publicitaires).
Le plus lamentable c'est de marcher les 2 pieds dedans en postant un lien en première des journaux de LinuxFR (site réputé pour avoir un google rank plus que bien placé).
Y'a 2 écoles de journalismes :
- ceux qui veulent informer les lecteurs
- ceux qui veulent vendre du service aux lecteurs en leur faisant lire ce qu'ils ont envie de lire.
Le vrai journaliste est de la première espèce, mais malheuresement le vrai journaliste a aussi besoin de manger, je suis pas sûr qu'on puisse le blâmer d'écrire des articles raccoleurs de la sorte.
Le contenus des articles des journaux ne sont finalement que le reflet de leurs lecteurs, qui sont les premiers responsables de ce qu'ils lisent en achtant la dite revue.

Valider ?
Valider la transaction ?
Valider les modifications ?

Si je comprend bien derrière un déguisement festif, voire culturel, il s'agit avant tout de publicité.
?
C'est annoncé noir sur blanc :
"Microsoft et le groupe F illumineront la Grande Arche le 30 Janvier 2007, à l’occasion de la sortie mondiale du tout nouveau système d’exploitation « Windows Vista » de Microsoft"
C'est clairement annoncé comme une pub, je vois aucune référence culturelle qui cache quoi que ce soit.

tu parles matos, je parlais logiciel, bref ce qui est à notre portée. Il semblait faire remarquer qu'on nous enfermait dans des solutions proprios sans nous laisser le choix. Moi je dis juste qu'il faudrait commencer par proposer un choix. Forcé de constater que même si Flash ca pu pour de nombreuses raisons, y'a aussi de nombreuses raisons pour l'utiliser (bonne ou pas), et certains ont besoin de ce genre de fonctionnalités (bonne ou pas).
Bref, sans même juger la techno flash en soit, je constate qu'on n'a strictement aucune alternative à proposer, qui soit standardisé, ouverte et bien sûr libre. Il est donc logique que la seule et unique solution du marché est 99% des parts du marché dans ce secteur. Bref, qu'on vienne pas pleurer. Le pire c'est qu'un concurrent arrive, et c'est encore MS, ca sera encore du proprio, et on va encore râler.