Monsieur,

Je vous écris en tant que représentant pour l'Europe francophone du projet PostgreSQL, ainsi qu'au nom de toute la communauté française de PostgreSQL (qui gère le site http://www.postgresqlfr.org/ et en attendant que se constitue une association loi 1901).

Dans le n°606 du 4 octobre 2004 de votre journal, Décision Informatique, vous avez publié un comparatif de cinq systèmes de gestion de bases de données (SGBD). Notre communauté a été contactée par votre mandataire, la société Clever Age, afin de l'aider à optimiser leur installation de PostgreSQL pour les tests qu'ils ont effectués. Par contre, la communauté n'a jamais été sollicitée sur d'autres points et il en résulte, dans votre article, un certain nombre d'erreurs, d'imprécisions et de confusions.

Par la présente, nous souhaitons donc vous demander un droit de réponse à votre article. En voici les points, classés par gravité. Nous avons inclus un certain nombre de références, afin de vous assurer que nous affirmations ne sont ni gratuites, ni biaisées.

Erreurs

• "uniquement GPL" (p.34): PostgreSQL est géré par une license BSD, encore plus ouverte que la GPL. Ainsi, PostgreSQL est totalement gratuit. Il peut donc être inclus dans un produit commercial, sans qu'aucune redevance ne doive être payée à qui que ce soit. De même, PostgreSQL peut être installé sur autant de serveurs que vous le souhaitez (par exemple, développement, pré-production, production), sans coût supplémentaire.
• "Pas de sauvegarde à chaud" (p.30 et ailleurs): c'est tout simplement faux. Des outils de base (tels que pg_dump et pg_dumpall) permettent de faire des sauvegardes sans arrêter la base de données.
• "Les SGBD propriétaires proposent en plus la gestion de XML" (p.31 et ailleurs): PostgreSQL dispose également d'outil permettant de gérer le XML. Il est vrai qu'ils ne font pas partie de l'installation de base, mais se trouvent sous forme de contributions séparées. Néanmoins ces outils existent.
• "(PostgreSQL): son installation laborieuse nécessite des compétences très pointues, rarement disponibles en PME" (p.29), "(PostgreSQL) installation et paramÈtrage: 90 Minutes" et "(PostgreSQL) nécessite des compétences pointues" (p.31): c'est très largement exagéré. Tout d'abord, pour la plupart des distributions de Linux, PostgreSQL est disponible sous forme d'installeur (RPM). Le paramétrage par défaut est excellent pour des besoins courants, notamment ceux d'une PME. Seul le paramétrage de la sécurité peut paraître un peu compliqué la première fois, mais il est très vite appris. La seule compétence qui semble vraiment utile ici est de savoir lire l'anglais!
  L'administration d'une base PostgreSQL est également d'une grande simplicité. Dans la plupart des cas, un petit script d'optimisation agendé pour tourner chaque jour suffit amplement.
• "Les bases de données propriétaires disposent en plus de fonctions supplémentaires qui garantissent une reprise sur incident rapide (option cluster, contrôle d'intégrité en continu, etc.)." (p.30): PostgreSQL propose la reprise sur incident rapide par le biais du mécanisme de "Write Ahead Log". Il s'agit d'un mécanisme équivalent à celui d'Oracle qui garanti une reprise sur incident au plus près.
  Quant au "contrôle d'intégrité en continu" essaieriez-vous d'insinuer par là qu'une base de données PostgreSQL pourrait contenir, à un instant donné, des données inconsistantes? Si c'est le cas, c'est absolument faux. PostgreSQL utilise le mécanisme MVCC (MultiVersion Concurrency Control), tout comme Oracle (documentation: http://www.postgresql.org/docs/current/static/mvcc.html. Ce mécanisme garanti la consistance des données de manière formelle.

Imprécisions

• "Pas de mécanisme de réplication" (p.31): certes, il n'y a pas de solution de réplication proposée par défaut et il n'existe pas non plus de solution synchrone. Mais on trouve des contributions, telles que Slony-1 (http://gborg.postgresql.org/project/slony1/projdisplay.php) qui permettent de faire de la réplication asynchrone, plus que suffisante dans la plupart des cas.
• "IBM annonce par exemple avoir réduit de 65% la charge nécessaire à l'administration quotidienne de sa dernière génération de serveurs." (p.29): permettez-nous d'être choqués. Après avoir affirmé que PostgreSQL était difficile à administrer, pour son concurrent DB2 vous vous contentez de citer une annonce d'IBM. N'auriez-vous donc pas testé réellement la charge que représente l'administration de chaque SGBD? C'est la conclusion qui semble s'imposer et elle jette une lumière très défavorable sur le sérieux de votre démarche.
• "assistance technique annuelle : 4500 euros TTC" (p.34): il serait intéressant de savoir d'où vous tenez ce chiffre. En tout cas, ce n'est pas le tarif le plus intéressant que l'on puisse trouver. Ainsi, PostgreSQL Inc., société de service spécialisée dans PostgreSQL propose un plan "Bronze" à partir de 1100$ par an, soit moins de 900 euros.

Confusions

• "Les outils open source sont fonctionnellement plus pauvres. Ils se limitent aux fonctionnalités de base (SQL). PostgreSQL, par exemple, ne prends pas en compte XML, ni les services web." (p.28) et d'autres phrases de la même trempe, tout au long de l'article: ces affirmations sont révélatrices d'une grande confusion, qui biaise les résultats de votre test. La fonctionnalité principale et essentielle d'une base de données est bien de gérer les données, avec un accès par le langage SQL. SQL Server, Oracle et DB2 représentent ce que l'on appelle des "serveurs d'applications" qui fournissent de nombreux services, entre autres et en particulier un SGBD.
  A ce titre-là, le monde Open Source n'est pas plus pauvre, et de loin, que le monde du logiciel propriétaire. Faut-il seulement rappeler qu'Apache est le serveur web le plus utilisé au monde?
  Votre comparatif ne peut mériter ce titre que s'il compare des produits équivalents, ce qui n'est pas le cas.

Si l'on voulait rentrer dans tous les détails, la liste serait hélas encore longue. Dans l'espoir que vous publierez ce droit de réponse dans son intégralité, nous avons tenté de faire au plus court, tout en soulevant les points qui nous semblaient les plus cruciaux. Nous espérons fortement que cette missive ne restera pas lettre morte.