Module de Paiement SIPS

Le plugin propose également la version 2 de SIPS, plus moderne, que nous vous conseillons d’utiliser si elle est supportée par votre banque

SIPS est le prestataire de paiement historique, géré par Atos, encore utilisé par les banques HSBC (ElysNet), BNP (Mercanet), La Banque Postale (Scellius), Société Générale (Sogénactif), LCL (Sherlocks) et Crédit du Nord (Webaffaires).
Il est en voie de désaffection grandissante car son API et son mode de fonctionnement sont clairement vieillissants.

Si votre banque utilise encore SIPS, choisissez plutôt un prestataire de paiement externe, plus moderne, qui vous offrira plus de fonctionnalités et plus de souplesse pour accompagner l’évolution de votre site.

Configuration du paiement avec SIPS dans le plugin Bank

Configuration

La configuration de ce module de paiement du plugin Bank se fait dans le menu Configuration > Paiements en ligne.

  • Service : Indiquez quel service vous utilisez (ce sont les noms commerciaux choisis par les banques qui utilisent SIPS : HSBC, BNP, La Banque Postale, Société Générale, LCL et Crédit du Nord).
  • Merchant ID : Numéro de marchand, numérique de 15 chiffres environ, fourni par votre banque.
  • Certificat : Contenu du fichier certificat certif.fr.xxxx associé à votre Merchant ID, fourni par votre banque.

Vous pouvez par ailleurs fournir les URLS des 3 logos Logo_id, Logo_id2 et Advert qui seront utilisés sur la page de paiement chez Atos.

Attention : L’utilisation de ce service nécessite l’installation de 2 binaires exécutables request et response qui seront fournis par votre banque, en fonction de la configuration de votre serveur (type et version de l’OS, 32/64 bits). Cela rend en général compliqué les tests sur un poste de développement qui n’a pas la même configuration.
Les binaires ne sont pas fournis par le plugin. Ils devront être installés dans le sous-dossier presta/sips/bin/ de votre dossier squelettes/.

Discussion

9 discussions

  • Bonjour,

    J’ai intégré ce qui manquait (3 fois rien) pour faire fonctionner Sherlocks2 de LCL.

    La PR est ici : https://github.com/nursit/bank/pull/103

    Attention :

    • il faut bien demander à LCL la version complète (et pas la version simplifiée mise à jour depuis Sherlocks 1).
    • bank générant la référence de transaction, il faut demander dans le contrat LCL à désactiver l’option de génération automatique de la part du serveur LCL.

    Répondre à ce message

  • 7
    Damien

    Bonsoir,

    J’ai un gros souci actuellement sur une boutique qui marchait très bien :
    PHP 5.6 - SPIP 3.2.3 - Bank 3.6.7 - Mercanet SIPS V1 qui stoppe en juin
    Un jour la partie carte affichait erreur appel request
    On s’est dit moment de passer en V2
    A l’essaie de paiement, j’ai eu le même message que Bilal : Une erreur s’est produite. Veuillez contacter votre commerçant.
    J’ai essayé son astuce qui ne marche pas pour la BNP

    Afin d’augmenter un peu la sécurité, j’ai fait une installation sur un autre serveur :
    Je ne peux pas encore passer en SPIP 4.0.6 ou 4.1 car pas mal de plugins sont incompatibles actuellement
    donc pour cette MAJ temporaire je suis en PHP 7.1 sinon certains plugins affiche des Warning dont Bank sur les liens des CB - SPIP 3..2.14 - Bank 5.1.1 - Mercanet V2 SIPS
    Mais j’ai toujours : Une erreur s’est produite. Veuillez contacter votre commerçant

    Mercanet BNP m’a envoyé ceci

    Votre boutique a fait l’objet d’une migration simplifiée/standard mercanet V2

    La construction de votre solution Mercanet V2 standard/simplifiée repose sur la technologie avec les connecteurs webservices de Mercanet V2, en POST, JSON, SOAP ou SDK INAPP

    Vous conservez le fonctionnement avec le principe du transaction_id (utilisation du champ s10TransactionReference.s10TransactionId).

    Vos transactions doivent être uniques sur une même journée et générées en 6 chiffres.

    Afin de préserver l’unicité de la transaction, le champ s10TransactionId doit être couplé avec le champ s10TransactionIdDate (à noter que celui-ci est directement alimenté par le serveur donc pas besoin de renseigner la date). Ce couple nous permet de créer le s10TransactionReference.

    Ainsi, le couple s10TransactionId/s10TransactionIdDate permet d’éviter les doublons de transactions.

    Pour vos transactions, vous devez donc impérativement utiliser le champ s10transactionId encodé comme suit :

    // $s10TransactionReference=array(

    // « s10TransactionId » => « 000001 »,

    // // « s10TransactionIdDate » => « not needed », Le serveur Mercanet va enrichir cette information automatiquement

    // ) ;

    //

    Votre champ data contiendra donc une valeur correspondant à s10TransactionReference.s10TransactionId=000001 suivant l’exemple ci-dessus.

    Le s10TransactionReference vous sera retourné dans la réponse du serveur Mercanet.

    Mercanet m’a expliqué qu’il y avait 2 versions de SIPS V2 simplifé ou complet. Est-ce du à cela ?

    Pourriez-vous m’aider SVP ?

    PS de plus pour le virement et le chèque, depuis le passage à la nouvelle config, C’est ces erreurs de code (pièce jointe)

    Merci beaucoup beaucoup d’avance

    • Bonjour @Damien, j’ai le même problème. Avez-vous trouvé une solution ?
      Merci !
      Éric LM

    • Bonjour Eric,

      Déjà une mise à jour complète de ce vieux site en SPIP 4.1 et PHP 7.4/8.0 générait trop d’erreurs donc (comme le bug des chèques par exemple) ma boutique est toujours en SPIP 3.2.3 et PHP 5.6 pour le moment, mais plugins bank à jour pour cette version.

      Alors après investigation, c’était bien ce que j’avais vu avec le service client. Mercanet a deux versions de SIPS 2. Une « simplifiée » qu’ils installent par défaut sans toujours prévenir le client (les conseillers en tout cas) et une deuxième version dite « complète ».

      Le plugin bank génère un champ $parm[’transactionReference’] qui marche avec la version complète, mais pas la simplifiée sauf si une mise à jour récente le prend en compte maintenant.

      Il faut donc demander à Mercanet ou via votre client, le passage sur la version « complète » de SIPS 2 et pas simplifié.

      En espérant avoir été clair :-)

      Bonne journée

    • Oh mon Dieu ! Quelle histoire ! C’est effectivement cela : la BNP nous a transféré en Mercanet v2 simplifiée.
      Il n’empêche que j’ai besoin de Spip 4 pour faire tourner un autre plugin...
      Un grand merci en tout cas ! C’est la deuxième fois que vous me sortez du pétrin !
      Bonne soirée,
      Éric LM

    • LOL... Avec plaisir.

      Ça prend environ une semaine le changement de Mercanet sans rien avoir à faire du côté plugin si vous avez déjà mis les clefs V2.

      Pour le SPIP 4, je précisais simplement. Mon site est un peu particulier et ancien et j’ai voulu tout mettre à jour d’un coup.

      Pour vous tout devrait bien se passer :)

      Bonne journée

    • Bonjour Damien, encore une petite question : avez-vous utilisé une boutique de test, (si oui laquelle ?) ou avez-vous directement travaillé en production, avec vos identifiants Mercanet 2 ?
      Merci,
      Éric

    • Eric,

      J’ai quasiment toujours deux versions d’un site : « prod » et « dev »,
      J’ai testé sur « dev » d’abord avec les clés de test de Mercanet et aussi fait un test réel sur dev en créant un produit temporaire de 1 euro puis j’ai appliqué les modifs à « prod ».

      Damien

    • Oui, mais quand je parle de « Boutique de test », je parle des boutiques de la BNP https://documentation.mercanet.bnpparibas.net/index.php/Boutique_de_test dont on utilise les identifiants pour faire fonctionner le plugin Bank en mode test.

      Manifestement, vous n’avez pas utilisé les boutiques de test de la BNP, vous avez travaillé directement avec vos identifiants Mercanet.
      Éric

    Répondre à ce message

  • 1

    Bonjour,
    Quelqu’un a-t-il déjà implémenté le module de paiement SIPS v2 avec Sogenactif avec succès ? Mon site passe la phase de test, mais en production un message d’erreur m’est renvoyé (« Une erreur s’est produite. Veuillez contacter votre commerçant »). Le support Sogenactif me demande en réponse de désactiver l’envoie de Transaction Reference au sein de mon CMS…
    Si jamais quelqu’un sait… merci d’avance.

    • Après investigation auprès du support Sogenactif, il s’avère que le module de paiement SIPS2 génère le champ TransactionReference dans ma requête de paiement. Or il s’avère que ma boutique auprès de la banque est paramétrée pour une génération automatique du champ TransactionReference. Cela me renvoie donc un message d’erreur.
      Dans le code du module j’ai par conséquent désactivé le champ TransactionReference ligne 85
      plugins/auto/bank/v5.0.13/presta/sipsv2/call/request.php

      $parm['transactionReference'] = bank_transaction_id($row);

      Et cela fonctionne parfaitement.
      Par contre n’y a-t-il pas un moyen de le désactiver en dehors du module, ce qui ne s’avère pas une solution satisfaisante et pérenne ?
      Merci d’avance si quelqu’un peu m’aiguiller.

    Répondre à ce message

  • 5

    Bonjour

    Dans une boutique équipée de notre plugin Banque&paiement v4.7.4
    je dois migrer de scellius v2 à scellius v3 de la Banque postale.

    Mais je ne parviens pas à passer la phase de test avec ce message d’erreur : « The merchant ID entered is not valid for this simulation environment. Please use the test merchant ID in the simulation environment. It is not possible to use a production merchant ID. »
    Et bien sur dans l’intreface bancaire je ne trouve aucun « test merchant ID ».

    En interrogeant le service technique de la banque postale scellius v3, le gars me dit « ah mais bon spip, nous on ne connait pas, on n’a pas certifié ce cms... ».

    Est-ce que quelqu’un d’autre utilse notre plugin en scellius v3 avec la Banque postale ?
    Et comment avez-vous réussi à passer cette phase de test ?

    • Salut yanic, je ne pense pas que Scellius v3 repose sur SIPS, mais probablement plus sur PayZen. Tu peux m’envoyer la doc ou les liens de doc que tu as, pour les URLs de serveur notamment ?

      Je pense qu’il faut simplement que je l’ajoute comme variante PayZen comme prévu ici mais pas testé faute d’utilisateurs utilisant ce service :
      https://github.com/nursit/bank/blob/master/presta/payzen/inc/payzen.php#L54

    • Donc je confirme que c’est bien la plateforme payzen de Lyra Network dans ce scellius v3 de la banque postale.

      J’ai donc remplacée l’url payzen par $host = « https://scelliuspaiement.labanquepostale.fr » ;
      là : bank/presta/payzen/inc/payzen.php L54
      et j’obtiens cette réponse de la plateforme :

      La transaction est définitivement perdue et n'est pas visible dans votre Back Office car incomplète.
      
      L'erreur rencontrée est liée au paramètre suivant :
      
      PaymentFormError = 00 - signature
      
      AVERTISSEMENT: Veuillez d'abord vérifier si votre système utilise la bonne valeur "vads_site_id" et la bonne "clé" disponible dans le back-office marchand. Pour gérer correctement les caractères spéciaux dans la signature, tous les champs doivent être exprimés en utilisant le codage UTF-8. Veuillez d'abord vérifier que votre système utilise bien le codage UTF-8.
      
      Paramètres attendus pour la signature : vads_action_mode + vads_amount + vads_contrib + vads_ctx_mode + vads_currency + vads_cust_address + vads_cust_city + vads_cust_country + vads_cust_email + vads_cust_last_name + vads_cust_zip + vads_language + vads_order_id + vads_page_action + vads_payment_cards + vads_payment_config + vads_return_mode + vads_shop_name + vads_shop_url + vads_site_id + vads_trans_date + vads_trans_id + vads_url_cancel + vads_url_check + vads_url_return + vads_version + certificate
      
      Chaîne de caractère (UTF-8) à encoder : INTERACTIVE+2367+SPIP 3.2.12 + Bankv4.7.4(https://github.com/nursit/bank)+TEST+978+79 boulevard Richard Lenoir+Paris+FR+webmaster@aphg.fr+Yanic Gornet+75011+fr+4563+PAYMENT+CB+SINGLE+GET+Association des Professeurs d'Histoire et de Géographie+https://www.aphg.fr+81219649+20220118122951+449913+https://www.aphg.fr/bank.api/payzen-B427/cancel/+https://www.aphg.fr/bank.api/payzen-B427/autoresponse/+https://www.aphg.fr/bank.api/payzen-B427/response/+V2+GEXXXXXXXXXXXXTJ
      
      Algorithme de signature attendu : HMAC-SHA-256
      
      Chaîne de caractère attendue (UTF-8) : [L91rUYVAWNpGUjadZDC0+FtVT1995Rw8SbNpGsgm1TU=]
      
      Chaîne de caractère reçue (UTF-8) : [gSV6G4i1Xt6QlOxqspOdxuA0brEgsOsvDRP0u2Zixfk=]
      
      Pour comprendre l'origine de ce problème se référer à la FAQ :https://scelliuspaiement.labanquepostale.fr/doc//fr-FR/error-code/error-00.html
      
      Pour information, voici le formulaire de paiement invalide reçu par notre plateforme :
      
      [signature=gSV6G4i1Xt6QlOxqspOdxuA0brEgsOsvDRP0u2Zixfk=]
      [vads_action_mode=INTERACTIVE]
      [vads_amount=2367]
      [vads_contrib=SPIP 3.2.12 + Bankv4.7.4(https://github.com/nursit/bank)]
      [vads_ctx_mode=TEST]
      [vads_currency=978]
      [vads_cust_address=79 boulevard Richard Lenoir]
      [vads_cust_city=Paris]
      [vads_cust_country=FR]
      [vads_cust_email=webmaster@aphg.fr]
      [vads_cust_last_name=Yanic Gornet]
      [vads_cust_zip=75011]
      [vads_language=fr]
      [vads_order_id=4563]
      [vads_page_action=PAYMENT]
      [vads_payment_cards=CB]
      [vads_payment_config=SINGLE]
      [vads_return_mode=GET]
      [vads_shop_name=Association des Professeurs d'Histoire et de Géographie]
      [vads_shop_url=https://www.aphg.fr]
      [vads_site_id=81219649]
      [vads_trans_date=20220118122951]
      [vads_trans_id=449913]
      [vads_url_cancel=https://www.aphg.fr/bank.api/payzen-B427/cancel/]
      [vads_url_check=https://www.aphg.fr/bank.api/payzen-B427/autoresponse/]
      [vads_url_return=https://www.aphg.fr/bank.api/payzen-B427/response/]
      [vads_version=V2]
    • La version 5.0.9 du plugin bank propose maintenant Scellius v3 comme sous-service du module SystemPay
      https://github.com/nursit/bank/commit/9a973369745b8b129699a318f055059cdf938a60

      Je t’invite à l’essayer en t’assurant que tu as bien la bonne clé, si tu es en mode test ou non, et le bon algo de signature (c’est normalement le SHA256 par défaut maintenant).

    • Bravo et merci !

      Scellius V3 de la Banque postale est désormais un mode de paiement disponible par cet extraordinaire plugin Bank. Il faut seulement spécifier que cela passe par le paramétrage du prestataire « Systempay (2A02) ».

    Répondre à ce message

  • 4

    Bonjour,

    Un mail de la Société Générale pour Sogenactif 1.0 signale qu’il faudrait passer à « Pour Linux : version 617_PLUGIN_linux32_f-3.2 ou 617_PLUGIN_linux64_f-3.2 »

    Est-ce que le plugin Bank tel que distribué par SVP (4.2.3) intègre cette mise à jour ?

    Le mail complet :

    Afin de supprimer une vulnérabilité présente et optimiser les performances des API actuelles, des mises à niveau techniques obligatoires sont disponibles, avec de nouvelles versions d’API Sogenactif 1.0.

    Nous vous demandons de télécharger et de mettre à jour l’API utilisée, via l’interface Sogenactif Téléchargement accessible via le lien ci-dessous (1)

    https://telechargement.sogenactif.com

    Vous pouvez utiliser votre identifiant et mot de passe habituels pour vous y connecter.

    Nos équipes de support se tiennent à votre entière disposition pour vous accompagner dans son déploiement ou pour toute autre question relative à ce sujet.

    Par ailleurs, nous vous proposons de migrer vers notre solution Sogenactif 2.0, qui propose de nouveaux connecteurs bénéficiant des dernières évolutions fonctionnelles et réglementaires.

    (1) : Nous préconisons l’utilisation des API suivantes :

    • Pour Windows : version 617_PLUGIN_win32_f ou 617_PLUGIN_win64_f

    • Pour Linux : version 617_PLUGIN_linux32_f-3.2 ou 617_PLUGIN_linux64_f-3.2

    Ces versions exploitent des fonctions de sécurité renforcée. Néanmoins, si votre système d’exploitation est antérieur à l’année 2014, vous pouvez vérifier la compatibilité de ces API avec votre environnement, en vous assurant que la version du noyau Linux est la 3.2 ou supérieure. Si ce n’est pas le cas, vous devez télécharger les API version 617_PLUGIN_linux32_f-2.6.18 ou 617_PLUGIN_linux64_f-2.6.18.

    Restant à votre écoute.

    • De ce que je comprends la mise à jour concerne les binaires distribués par la banque, et ils ne sont pas fournis par le plugin. C’est à toi de les mettre à jour sur ton serveur le cas échéant

      (mais le bon conseil c’est surtout de passer à SIPS v2 ou de changer de prestataire de paiement, SIPS étant tellement dépassé techniquement...)

    • Merci de ta prompte réponse.

      Sauf erreur de ma part, le plugin bank intègre 2 binaires SIPS
      https://github.com/nursit/bank/tree/master/presta/sips/bin

      1. request
      2. response

      Le commit qui les a placé là : https://github.com/nursit/bank/commit/cf8da850c3e5e7416baad35894e9f48cbdb06432#diff-78bb4f7e1bab04f077843907e7ad1959

      Donc, est-ce que le courrier de la Société Générale s’applique à tous les prestataires utilisant SIPS (v1), ou est-ce que changer ces 2 binaires casserait les autres (les sous dossiers de https://github.com/nursit/bank/tree/master/presta/sips/bin) ?

    • Il y a 2 binaires dans le plugin, mais sans garantie qu’ils fonctionnent car cela dépend de la plateforme.

      Je cite la doc ci-dessus :

      L’utilisation de ce service nécessite l’installation de 2 binaires exécutables request et response qui seront fournis par votre banque, en fonction de la configuration de votre serveur (type et version de l’OS, 32/64 bits). Cela rend en général compliqué les tests sur un poste de développement qui n’a pas la même configuration.
      Les binaires ne sont pas fournis par le plugin. Ils devront être installés dans le sous-dossier presta/sips/bin/ de votre dossier squelettes/.

       :)

      Donc en conclusion je ne fais pas de support sur les binaires - et si ils semblent que les mêmes binaires puissent être utilisé pour toutes les banques je n’ai aucune certitude sur le sujet, car ce n’est ni marqué dans la doc, ni garanti par qui que ce soit, c’est juste empirique

    • Merci beaucoup pour cette réponse.

      Et j’ai été induit en erreur parce qu’au lieu de lire la doc, j’ai lu les dossiers du plugin qui contiennent des binaires qui finalement ne sont pas sensés servir.

      En tout cas, j’ai ma réponse. Merci.

    Répondre à ce message

  • 3

    Bonjour Cerdic,

    Je reprends le message de Sonia : « Une erreur m’indique erreur appel request executable request non trouve alors même que les 2 fichiers (exécutables request et response) de la banque se trouvent au bon emplacement squelettes/. dans le répertoire précité : presta/sips/bin/ »

    Je rajoute : Le CHMOD des fichiers est à 715 et j’ai essayé stritic/glibc.

    Auriez-vous me donner des pistes pour tenter de résoudre le problème ?

    Merci d’avance

    Damien

    • Bonjour Damien, j’ai le même problème. Avez-vous trouvé la solution ? Savez-vous où il faut placer ces deux fichiers ?
      Merci,
      Eric LM

    • Bonjour Eric,

      Comme expliqué par l’aide de SPIP : "L’utilisation de ce service nécessite l’installation de 2 binaires exécutables request et response qui seront fournis par votre banque, en fonction de la configuration de votre serveur (type et version de l’OS, 32/64 bits). Ils devront être installés dans le sous-dossier de VOTRE DOSSIER DE SQUELETTES/presta/sips/bin/.

      POUR MOI, c’était juste que la banque, via leur site, m’a donné tous les request/response, tout système confondu, et j’ai testé chacun d’entre eux pour trouver les « bons fichiers » à mettre. Pour les tests, pensez bien à mettre des ID, MERCHANT ID de demo.

      Je passe par Mercanet (BNP) et j’avais deux dossiers : linux32 et linux64 et dans ces dossiers, dans le dossier bin, j’avais la version glibc et static. La version qui a marché pour moi c’est linux64 et version glibc.

      A chaque changement, pensez à vider le cache au cas où.
      Damien

    • Un grand merci Damien. Je viens de réussir : les fichiers étaient bien au bon endroit, mais ils devaient avoir les droits 755. Avec cela, je me connecte à la page de paiement.
      Merci d’avoir pris le temps de répondre, et bonne journée !
      Eric

    Répondre à ce message

  • 1

    Bonjour,

    une erreur m’indique erreur appel request executable request non trouve alors même que les 2 fichiers (exécutables request et response) de la banque se trouvent au bon emplacement squelettes/. dans le répertoire précité : presta/sips/bin/

    Pourriez vous me donner des pistes pour tenter de résoudre le problème ?

    CHMOD ? Fichier oublié ? Fichier non transférable d’un serveur à l’autre ???
    Merci pour vos conseils.

    Répondre à ce message

  • 1

    Bonjour.

    J’essaie d’utiliser ce plugin car celui-ci me parais super-adapté puisqu’une extension de Formidable.
    Spip 3.1.1 Formidable et tout (j’ai pas trop de plugins) à jour.

    J’ai testé les cgi-bin de test sur mon serveur et cela a marché. Je précise que le certificat est livré désormais en .php (ou .asp). La conf apache est nickel et php.ini (safe_mod=off) aussi.

    J’ai donc copié mes binaires cgi dans :
    /var/www/.../plugins/auto/bank/presta/sips/bin (modifié apache en conséquence)

    J’ai cru comprendre qu’il fallait copier le contenu du certificat dans la case idoine.
    Ce que j’ai fait. Mais ça couine ;-)

    J’ai un « API ERROR Error reading certificate data at line ( »
    et un extrait de ce certificat.
    Je précise que j’ai copié ce qui est entre
    /*__DEBUT_
    et
    ++END__FIN__*/
    et testé aussi avec

    <?php.../php>
    
    l'API qui est fâchée c'est celle de Webaffaires (SIPS) ? Est-ce autre chose ?
    Me trompe-je quelque part ?
    
    Merci de m’éclairer.
    
    • Bonjour,

      J’avais le même problème avec un certificat de la banque postale. Je n’ai copié dans le champ « certificat » que le texte « binaire », j’ai supprimé le début jusqu’à « certificate_data ! » inclus. Et j’ai supprimé aussi la fin (balise fermante php).
      Comme j’ai bien galéré, j’espère que ça pourra être utile !

    Répondre à ce message

  • Sur OVH quel chmod pr les executable ?

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom