Avec un SPIP 1.9.2c installé sur Windows Server 2003 SP2, avec Apache 2.2.6 et PHP 5.2.4, j’avais des plantages étranges sur la page de configuration avancée de SPIP et l’indexation ne marchait plus bien, certains articles passant au travers. Je n’avais pas ce soucis sur le même site déployé sur Linux ou Mac OS X.

Après bien des essais et lectures de code tant perso que de SPIP, il s’avère que PHP supporte mal l’usage simultané de sessions et de exec(). Le bug #22526 a beau dater de 5 ans et être clos, le problème se pose encore, manifestement.

J’avais en fait un session_start() dans mes_options.php pour avoir une session PHP active dans toutes les pages. Du coup j’avais un plantage, tant des exec() de test de librairies graphiques dans la configuration avancée, que des exec() d’extraction de contenus des documents dans l’indexation.

De proche en proche, j’ai découvert sur différents forums que le problème est bien d’actualité, et qu’heureusement une solution existe !

Il suffit de remplacer toutes les instructions telles que la suivante :

Par ceci :

Bien sûr, si le exec() en question se trouve après du code écrivant sur la sortie standard, il faudra utiliser les fonctions de bufferisation de sortie [1] pour éviter les warning dûs à l’envoi de cookie par session_start().

Bien que les sources qui relatent ce problème et sa solution datent un peu, je peux vous confirmer que modifier de cette façon le source des fichiers présents dans ecrire/extract/*.php résout bien le problème.

Finalement, les sessions de SPIP sont meilleures que celles de PHP, au moins sur ce point...

Malheureusement, le forum dans lequel est proposé ce modèle n’est pas ouvert aux commentaires, donc je réagis ici, au risque de faire gonfler l’affaire plus que nécessaire...

Je comprends qu’il soit très confortable, quand on développe un logiciel, de s’appuyer uniquement sur le dernier cri des fonctionnalités d’une technologie.

Mais de là à exiger des hébergeurs qu’ils suivent le mouvement sous prétexte que le logiciel en question est populaire [2], il me semble qu’on n’est pas loin de l’abus de position dominante.

C’est à chaque hébergeur de se faire sa propre idée en ce qui concerne la pertinence du passage à PHP5. Il ne suffit pas de dire que « PHP5 est disponible depuis près de deux ans et que cette version est stable », même si c’est vrai, pour que ce passage devienne une « évidence » pour l’hébergeur !

Quelques points en vrac qui pourraient justifier mes propos :

• * PHP4 est à priori plus stable que PHP5, puisqu’il y a plus d’historique et toujours une maintenance active [3]. La stabilité de PHP5, même bonne, est donc toute relative.
• * La plupart des projets logiciel libre ou développés en spécifique par tout un chacun sont clairement plus probablement faits en — et pour — PHP4, et ne fonctionnent pas — ou mal — en PHP5. Si l’hébergeur change de version, ce sont la plupart de ses clients qui risquent de changer de crèmerie, ce qu’aucune société commerciale n’est à priori prête à risquer.
• * D’autres projets se permettent de tirer profit des nouveautés de PHP5 s’il est disponible, mais continuent à bien fonctionner sur PHP4.

Je pense donc qu’il faut absolument :

• * d’une part que DotClear 1 continue à vivre — longtemps s’il le faut [4] — et soit mis à jour quand des bugs ou failles de sécurité sont identifiés
• * d’autre part que les développeurs de logiciels libres qui visent le grand public soit toujours humbles, surtout quand leur communauté commence à grossir

Ajout du 7 juillet

Apparemment, Free est maintenant compatible avec DotClear 2.0 [5], ce qui est un élément à mon avis essentiel pour la propagation de cette nouvelle version.

Le premier exemple intéressant va dans le sens de la nouvelle version « serialized php » de l’API de Yahoo : php_serial

Mais vous pouvez tenter toute sorte de formats :

• * php
• * yaml
• * sql
• * json
• * rdf

Malheureusement, ce n’est valable que pour les flux de syndication, et pas encore pour l’API de Flickr, mais cela ne saurait tarder, ils travaillent dessus.

Cela devrait à n’en pas douter booster la création d’applications exploitant l’API Flickr.

Alors que REST semble recevoir de plus en plus de suffrages face à la lourdeur et complexité de la constellation WS-* qui gravite autour de SOAP [1], voilà qui pourrait bien favoriser l’éclosion d’une nouvelle race de Web Services.

Il est en effet bien plus simple de générer un tableau Javascript à partir de contenu au format json que de parser du XML. Sans compter l’économie en bande passante et en temps de traitement, tant côté client que serveur.

Par contre, il manque deux choses pour que le modèle d’architecture REST soit respecté :

• # le type de contenu devrait être correctement indiqué dans l’en-tête HTTP de la réponse du service web (Content-Type : xxx)
• # et de même, le client devrait indiquer le format qu’il désire dans l’en-tête HTTP de sa requête et non dans une variable GET.

L’identificateur du format désiré (json, xml, rdf, ...) est une méta-donnée de représentation et non pas une identification de la ressource (dans l’URL). Pour faire une analogie, on retrouve un peu ici le problème de séparation entre contenu et présentation des outils de gestion de contenu Web, la spécification HTTP prévoit une en-tête pour ça (Accept) [2].

source

IBM avait déjà expliqué dans un de ses fameux Redbooks comment mettre en oeuvre PHP sur un IBM eSeries, mais c’est maintenant une vraie implication qui est annoncée par un partenariat avec Zend [1].

La concrétisation de ce partenariat est le produit Zend Core for IBM, qui est présenté comme une version particulière de PHP s’intégrant facilement avec les bases de données DB2 et Cloudscape, offrant un support natif de XML et des Web Services, et favorisant l’adoption d’architectures orientées services (SOA) [2].

Au delà de l’effet d’annonce [3], et alors que Sun peine toujours à réduire le ticket d’entrée de Java, voilà une nouvelle preuve de l’intérêt croissant du monde professionnel pour la plateforme PHP, après notamment l’annonce de partenariat entre Sun et Zend l’an dernier pour faire de PHP l’implémentation de référence de la JSR 223, dont le but est de permettre d’utiliser un autre langage de scripting que les JSP.

Petite chronologie

Le 12 juin 2002, Stig Bakken, leader du développement de PHP pour sa version 4.3, met à jour la licence pour cette version. Le paragraphe 6 qui indiquait que le Zend Engine est inclu dans PHP est supprimé, et est remplacé par une simple mention de ce Zend Engine en fin de texte. Le numéro de licence passe du même coup de 2.02 à 3.0a1.

Le 21 juillet 2002, Stig Bakken, toujours lui, intervient plusieurs fois sur la licence, principalement pour scinder en deux le paragraphe 3 qui parle à la fois du nom PHP et de l’usage qu’il en est fait pour nommer les logiciels développés en PHP. La séparation en deux paragraphe simplifie la compréhension de la seconde partie, qui devient donc le paragraphe 4 suivant :

Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

Soit en français :

Les produits dérivés de ce logiciel ne devraient pas être appelés "PHP", et "PHP" ne devrait pas apparaître dans leur nom, sans autorisation écrite préalable de group@php.net. Vous pouvez indiquer que votre logiciel fonctionne avec PHP en disant "Foo pour PHP" plutôt qu’en l’appelant "PHP Foo" ou "phpfoo".

Dans la foulée, Derick Rethans demande dans la mailing-list php-cvs si phpMyAdmin et phpOpenTracker sont considérés comme des logiciels dérivés de PHP, selon le nouveau sens proposé par la licence.

Le 5 août 2002, Sebastian Bergmann, créateur de phpOpenTracker, répond en passant dans la mailing-list plus appropriée php-dev qu’il est naturellement lui aussi intéressé, puisque directement concerné.

C’est alors que Rasmus Lerdorf, créateur de PHP que l’on ne présente plus, intervient pour préciser ce qu’il en pense et en a déjà dit à plusieurs reprises auparavant. En synthèse, les projets développés en PHP n’ont aucune raison d’avoir des noms comportant PHP, alors que cela n’est pratiqué dans aucune autre technologie.

Le 4 septembre 2002, sans doute pour l’exemple, Rasmus Lerdorf interpèle Michael Glazer, créateur du projet PHPortal, pour lui demander pourquoi le nom de son projet contient ’php’.

Le 6 septembre 2002, Rasmus, toujours lui, annonce dans la mailing-list pear-dev que suite à une discussion avec Richard M. Stallman, la liste des licences logiciel libre non compatibles avec la GNU/GPL a été mise à jour pour prendre en compte la nouvelle version de la licence PHP et ôter les réserves importantes qui étaient faites sur la pertinence de la version précédente.

A bin oui, mais alors ...

Cette habitude de mettre PHP dans le nom des logiciels, très particulière en effet, a sans doute trouvé sa source dans phpMyAdmin, assurément le plus fameux des projets PHP.

C’est d’ailleurs exactement ce qui a conduit aux noms de phpMyChat, qui était initialement basé uniquement sur PHP et MySQL, mais aussi de phpLang, phpApp, phpXMLP et phpSyndication.

Pour les autres projets, cela n’aurait sans doute que peu d’impact, mais un changement de nom de phpMyChat est-il envisageable alors qu’il est depuis déjà pas mal de temps connu de miliers d’utilisateurs ?

Bonus

Toutes ses discussions auront aussi permis de découvrir grâce à Yasuo Ohgaki que PHP est une marque déposée en 1947 au Japon par l’éditeur PHP Sougou Kennkyusho.

Introduction (à écrire !)

Ceci est un tutoriel sur l’utilisation de l’extension PEAR DB.

PEAR DB est un ensemble de classe proposant :

• abstraction de bases de données
• gestion avancée des erreurs
• etc

Obtenir et installer Pear

Pour le moment, le projet PEAR est encore fortement en développement, donc le meilleur moyen de l’obtenir est depuis le CVS (la distribution de PEAR DB livrée avec PHP est obsolète, même celle avec PHP 4.0.6 !). Ensuite, la seule chose que vous avez à faire est d’ajouter le répertoire racine de PEAR au paramètre include_path de votre fichier php.ini. Vous pouvez aussi procéder comme ceci :

Voici un exemple pas à pas :

La documentation complète du CVS PHP peut être trouvée ici.

Notez que PEAR DB nécessite PHP > 4.0.4, mais d’autres packages de PEAR comme le parser XML Parser ou le script pear installer nécessitent PHP >= 4.0.5.

Pour l’instant, ce guide couvre la dernière version CVS de PEAR DB, mais il peut être valide pour toute version récente.

Utilisation de PEAR DB

Se connecter et se déconnecter d’une base de données

La chaine de connexion Data Source Name (paramètre $dsn dans l’exemple ci-dessus) peut avoir les formats autorisés suivants (copie directe de la méthode parseDSN de pear/DB.php) :

Les bases de données actuellement supportées (partie phptype du DSN) sont :

Notez que certaines fonctionnalités peuvent ne pas être supportées par tous les gestionnaires de bases de données. Référez-vous au document donnant le status des extensions PEAR DB situé dans <pear base dir>/DB/STATUS pour avoir la liste détaillée.

Effectuer une requête dans la base de données

Récupérer les enregistrements résultant de la requête

Fonctions fetch

Plutôt que fetchRow() vous pouvez utiliser fetchInto() qui renseigne directement la valeur $row :

Sélectionner le format de l’enregistrement récupéré

Les modes de fetch supportés sont DB_FETCHMODE_ORDERED (par défaut), DB_FETCHMODE_ASSOC et DB_FETCHMODE_OBJECT.

Exemples de structures de données retournées par les méthodes fetch :

Configurer le format des enregistrements retournés

Vous pouvez indiquer quel mode de retour utiliser aux méthodes fetchRow() et fetchInto() ou définir un mode par défaut pour l’instance de DB.

Récupérer les enregistrements par indice

Le système de fetch de PEAR DB supporte aussi un autre paramètre pour permettre de récupérer les enregistrement par leur indice numérique. Cela est particulièrement intéressant si vous souhaitez exploiter seulement une partie d’un ensemble de résultats (par exemple pour contruire des listes paginées), récupérer les enregistrements dans un ordre particulier, etc.

Vider le résultat

Une fois que vous avez terminé d’utiliser le résultat, vous pouvez le vider avec la méthode free() :

Récupération rapide de données

PEAR DB fourni quelques méthodes particulières pour récupérer le résultat d’une requête sans avoir besoin d’utiliser fetchRow() pour le parcourir. Ce sont les méthodes getOne, getRow, getCol, getAssoc et getAll. Voici quelques exemples d’utilisation :

La famille des méthodes get*() fait tout le "sale boulot" pour vous, c’est à dire : exécuter la requête, récupérer les données et vider le résultat. Notez que comme toutes les fonctions de PEAR DB, elles retourneront un object PEAR DB_error en cas d’erreur.

Obtenir plus d’informations sur le résultat des requêtes (numRows, numCols, affectedRows, tableInfo)

Avec PEAR DB vous avez plusieurs façons d’obtenir des informations intéressantes sur les résultats de requêtes. Ce sont :

• numRows() : Donne le nombre total d’enregistrements retournés par une requête de type "SELECT".
• numCols() : Donne le nombre total de colonnes retournées par une requête de type "SELECT".
• affectedRows() : Donne le nombre d’enregistrements affectés par une requête de manipulation de données ("INSERT", "UPDATE" or "DELETE").
• tableInfo() : Donne un tableau associatif contenant des informations sur les champs retournés par une requête de type "SELECT".

Exemples d’utilisation :

Séquences

Les séquences sont un moyen d’obtenir des IDs uniques pour les enregistrements. Si vous faites la majeure partie de votre travail avec par exemple MySQL, pensez aux séquences comme un autre moyen de gérer AUTO_INCREMENT. Cela est relativement simple, tout d’abord vous demandez un ID, puis vous insérez cette valeur dans le champ correspondant du nouvel enregistrement que vous êtes en train de créer. Vous pouvez avoir plus d’une séquence pour toutes vos tables, mais assurez-vous que vous utilisez toujours la même séquence pour une table particulière.

Prepare & Execute/ExcuteMultiple (pas encore écrit)

autoCommit, commit and rollback (pas encore écrit)

Liste des méthodes disponibles

Gestion des erreurs

Récupérer le message d’erreur d’une erreur PEAR DB

Toutes les erreurs retournées par PEAR DB sont des objets PEAR Error. Voici un moyen de récupérer leurs informations :

Débuguer les erreurs PEAR DB

PEAR DB utilise un système de messages d’erreur portable pour signaler les erreurs à l’utilisateur. Cela a beaucoup d’avantages comme proposer un moyen simple de les transposer en autres langages ou réaliser une action spécifique en cas d’erreur spécifique. Mais cela ne donne pas beaucoup d’informations au développeur sur ce qui est arrivé. Pour récupérer l’erreur réelle donnée par le gestionnaire de bases de données ainsi que la dernière requête effectuée, vous pouvez utiliser la méthode getDebugInfo() :

Normalement quand une fonction PHP échoue, un message d’erreur est affiché. Dans PEAR ce fonctionnement a été désactivé. Mais peut-être aurez-vous parfois besoin de visualiser ces messages pour ôter des erreurs obscures de votre code. Cela peut être fait avec la fonction PHP set_error_handler qui est documentée dans le manuel PHP. Voici un exemple simple :

Exécuter autmatiquement des actions en cas d’erreur

Comme vous pouvez le voir, PEAR DB fait d’intenses vérifications et rapports d’erreurs, fonctionnalité qui oblige le développeur à toujours vérifier si le résultat de son action est ou non une erreur. PEAR DB prend aussi en charge cette tâche pénible, et propose un système très flexible pour automatiquement exécuter des actions en czas d’erreurs.

Les actions possibles sont :

• Retourne l’objet erreur (PEAR_ERROR_RETURN). C’est l’action par défaut.
• Imprime le message d’erreur (PEAR_ERROR_PRINT)
• Imprime le message d’erreur et arrête l’exécution (PEAR_ERROR_DIE)
• Utilise la fonction PHP trigger_error() pour lever une erreur PHP (PEAR_ERROR_TRIGGER)
• Passe l’objet erreur à une fonction ou à une méthode d’objet (PEAR_ERROR_CALLBACK)

Un exemple simple :

Un exemple plus complet :

Référez-vous au manuel de référence de PEAR pour obtenir la description détaillée des différentes actions possibles.

Voici une idée pour créer un système étendu de gestion d’erreurs :

Remerciements

Remerciements particuliers à Stig pour avoir créé le merveilleux monde de PEAR, aux personnes qui m’aident à maintenir ce document et bien sûr aussi à l’ensemble de l’équipe PEAR pour son travail permanent dessus.

Qu’est-ce que PEAR ? Et pourquoi devrais-je m’en préoccuper ?

Le projet PEAR (NDT : PHP Extension and Application Repository) a été lancé par Stig S. Bakken pour créer un outil similaire au CPAN de Perl. Son but principal est de devenir un entrepôt pour des extensions et scripts PHP. Le but le plus ambitieux du projet est de tenter de définir des standards qui puisse aider les développeurs à écrire du code portable et réutilisable.

De la documentation sur le projet commence à apparaître sur Internet, en concéquence certainement de sa popularité grandissante. Une documentation de départ peut déjà être trouvée dans le manuel officiel de PHP et sera augmentée.

PEAR est encore particulièrement en travaux, notamment le "PEAR installer" et le site dédié, et il devrait beaucoup croître dans les mois à venir. Il y a de nombreuses discussions sur la mailing-list des développeurs de PHP à propos de l’usage de PEAR dans les versions futures pour gérer le nombre croissant d’extensions C et aussi de l’usage du "PEAR installer" comme interface pour que les utilisateurs téléchargent et installent des extensions PHP.

Tout cela sans mentionner la librairie de scripts PHP de PEAR, qui est souvent considéré comme une des plus propre et bien conçues disponible actuellement pour PHP. L’un de ses composants les plus populaires est PEAR ::DB, la librairie d’abstraction de base de données créée pour ce projet. Bakken travaille même au portage des classes et fonctions principales en une extension C pour rendre le composant aussi rapide que possible.

Ce nouveau projet deviendra sûrement l’un des aspects les plus importants de PHP dans le futur, autorisant les développeurs à partager du code en utilisant le site de PEAR et en donnant aux utilisateurs l’opportunité de télécharger et installer des extensions et scripts PHP.

Comment puis-je débuter avec PEAR ?

Comme mentionner précédemment, PEAR continue à évoluer et à s’améliorer. Cependant, un certain nombre de composants sont maintenant utilisables. Le plus populaire est PEAR ::DB, qui permet au développeur d’écrire du code qui puisse être utilisé avec différents gestionnaires de bases de données. Par exemple, un développeur pourrait écrire un script qui insèrerait un enregistrement dans une table, et il fonctionnerait avec MySQL, PostgreSQL et Oracle.

Ainsi, l’exemple ci-dessous pourrait être utiliser avec tous les types de gestionnaires de bases de données (NDT : voir l’erratum en fin de page) :

C’était juste un très simple exemple pour montrer à quoi ressemblerait le code avec une librairie d’abstraction comme PEAR ::DB.

Un nouveau chapitre a été récemment ajouté au manuel de PHP, mais il est encore incertain si ce manuel contiendra la documentation complète de tous les composants de PEAR, ou si un nouveau manuel sera créé uniquement pour les composants de PEAR.

Procédures d’installation

Installer PEAR est en fait très simple, et je vais expliquer comment installer la dernière version du CVS de PEAR, qui change si rapidement.

Note : Le mécanisme interne de gestion de l’entrepôt changera probablement dans le futur. Pour l’instant, les composants et librairies sont stockés dans le même arbre CVS que PHP, ce qui pose des problèmes pour gérer à la fois les entrepôts et développeurs de PHP et de PEAR. Dans un futur proche, il est prévisible que PEAR sera détaché dans son propre module. Ce module existe, mais la plupart des composants sont encore dans l’ancien.

Installer PEAR à partir du CVS

Si vous n’avez jamais entendu parler de CVS, jetez un oeil à sa documentation. Ce n’est pas une technologie difficile d’usage, mais s’y accoutumer prend du temps.

En supposant que vous avez le client CVS standard installé sur votre machine, vous devrez suivre ces étapes :

1. Ouvrez une fenêtre de terminal (rxvt, xterm, ou autre)

2. Tapez les commandes suivantes :

Voilà. Lancer buildconf devrait créer le script configure standard qui peut être utilisé pour définir vos paramètres pour PHP. Pour une installation normale, PEAR devrait être automatiquement installé dans /usr/local/lib/php, mais vous pouvez installer les fichiers manuellement en allant dans ’php4/pear’ et en lançant make install-su en tant que superuser.

Ensuite, vous devriez ajouter le répertoire racine de PEAR à l’include_path de votre fichier php.ini. Le chemin par défaut devrait être /usr/local/lib/php, mais cela peut être ailleurs si vous avez effectué des modification manuelles de vos paramètres de configuration.

Débuter avec PEAR

Les composants de PEAR vont de l’abstraction de base de données à la gestion de cache, ce qui fait de PEAR plus qu’une simple librairie, c’est un nouveau standard pour écrire du code PHP portable et propre. L’une des plus importantes choses à faire pour un débutant avec PEAR est de lire les styles de codage PEAR qui sont publiés dans le manuel de PHP.

Je donnerais quelques conseil pour commencer à travailler avec PEAR ::DB, car c’est un des composant de PEAR les plus populaires. Vous pouvez trouver des exemples et de l’aide pour utiliser PEAR ::DB en suivant ces étapes :

• Cherchez des réponses à vos question sur MARC, dans pear-dev ou pear-general.
• Lisez les scripts de tests unitaires fournis avec le code source de PEAR. L’emplacement de ces scripts peut être trouvé dans le répertoire où se trouve votre image CVS de PHP. Dans mon cas, c’est /home/jpm/php4/pear/DB/tests/.
• Parcourez l’excellent tutoriel PEAR ::DB de Tomas V. V. Cox. J’espère que cet article a jeté un peu de lumière sur le mystérieux PEAR, et qu’il vous a fourni des informations utiles sur l’un des développements les plus prometteurs de la communauté PHP.

Amusez-vous !

Joao Prado Maia est développeur Web à San Francisco. Il a plus de quatre ans d’expérience en développement d’applications web et aime apprendre de nouvelles technologies et de nouveaux langages de développement.

phpMyChat : le chat en open source

L’article dans le JdNet

Il est possible de confier la mise en place d’un service de chat à un prestataire, mais il est aussi possible de le faire soi même, de nombreuses applications disponibles sur le net le permettant. C’est par exemple le cas de phpMyChat, une application PHP développée en open source par Nicolas Hoizey (qui travaille par ailleurs pour la web agency SQLI), et Loïc Chapeaux, ainsi que de nombreux contributeurs disséminés de par le monde. Ainsi, l’application est disponible en 32 langues. Elle est actuellement utilisée par de nombreux sites, comme par exemple Gastero Prod. Des prestataires de services l’utilisent aussi pour mettre en place des solutions de chat pour leurs clients. En effet, cette application étant open source, il est possible de l’adapter à des besoins particuliers.

Une solution fonctionnelle rapidement

Selon Nicolas Hoizey, créateur de la solution, "si l’on dispose d’une plate-forme avec Apache, PHP et MySQL, le chat est opérationnel en 5 minutes". Il est ainsi possible de l’installer rapidement chez la plupart des hébergeurs en colocation, et même chez des hébergeurs gratuits comme Free. L’application est paramétrable, notamment à l’aide d’une feuille de style CSS, ce qui permet de l’adpater à une charte graphique précise. Les bases de données MySQL, PostGreSQL sont supportées, ainsi que celles qui sont accessibles en ODBC. La connexion à la plate-forme s’effectue par le biais d’une simple page HTML contenant des frames invisibles rafraîchies périodiquement et assurant l’affichage des nouveaux messages. Une telle solution technique permet notamment un maximum de compatibilité et une utilisation derrière un firewall.

Les avantages du développement collaboratif

Les utilisateurs du chat peuvent, avec cette solution, créer leur propre salon. Des fonctions de modération sont aussi incluses. Il est ainsi possible de définir une liste de mots qui seront automatiquement remplacés par des caractères déterminés. Il est aussi possible d’exclure des utilisateurs abusifs. Par contre, il est impossible d’être alerté de l’utilisation de certains mots, mais cette fonction peut facilement être implémentée. Une liste de diffusion regroupe en effet plusieurs centaines d’utilisateurs de PHPMyChat, ce qui permet aux développeurs de coller à leurs attentes. Au programme des prochaines évolutions : l’intégration de l’identification à une identification générale, une couche d’abstraction pour les bases de données, et un renforcement de la sécurité.

Ludovic Blin, JdNet.

La couverture du magazine

Première page de l’article

Seconde page de l’article

Troisième page de l’article