Parce que les bonnes astuces nécessitent d’être partagées : Pour récupérer en local le contenu des « pull request » de github
Catégorie : Technique
-
Retour sur la première semaine – livre webperf
J’ai ouvert le projet pour partager mon début de livre sur la performance des sites web via github il y a une petite semaine. Il est temps de faire un premier point.
Tout d’abord « merci ». J’ai eu plus de retours que je n’en espérais la première semaine. Le niveau de correction des premier chapitres a dépassé celui des multiples relectures que dont j’avais déjà pu bénéficier. Ce n’est pas grand chose en soi mais une multiplication de petites fautes, c’est ce qui fait la différence entre une bonne lecture et un livre pénible à ouvrir.
Au niveau de la technique je confirme tous les techos qui disent que github est un bonheur. Le système de pull request et de commentaires associés est infiniment mieux que ce que je faisais dans un pas si lointain passé avec des patchs envoyés par mail. La facilité de contribution vient de là. Je regrette toutefois ne pas pouvoir exclure/inclure ligne à ligne une contribution envoyée par pull request. Là c’est du tout ou rien, et c’est dommage pour ce projet particulier.
Le contenu a lui été converti bien plus vite que prévu grâce à la contribution de Yoav. Pour ceux qui le souhaitent, il y a désormais un script de conversion ODT -> Pandoc qui produit un code assez bon.
Le gros défi à venir c’est l’évolution de ce contenu. Jusqu’à maintenant les contributions se sont concentrées exclusivement sur des corrections de typo ou de formulation, et deux sur les outils. Pour que le projet vive, pour que je n’en sois plus le seul détenteur, et pour arriver à un contenu complet, il faut que le contenu soit mis à jour, enrichi et étendu.
Bref, maintenant nous avons (aussi) besoin de contributeurs sur le contenu lui-même. N’ayez pas peur, c’est un très bon moyen de progresser et de se confronter aux autres. Il n’y a pas de risques à part celui d’apprendre.
-
Livre collaboratif, c’est lancé
Voilà, c’est fait. J’ai commencé la retranscription de mon livre sur la performance des sites web vers github pour en faire un projet collaboratif.
Vous retrouverez l’avant-propos et le premier chapitre d’introduction. Pour la suite je vais avoir besoin de vous comme promis :
- Vous avez un bon français écrit ? Nous avons besoin de relecture pour corriger les rares fautes, pour améliorer les formulations, retirer les répétitions, réaliser un meilleur découpage des paragraphes et globalement relever le niveau de français.
- Vous n’avez pas peu de faire un peu de code simple ? Nous avons besoin de personnes pour retranscrire les fichiers sources OpenDocument en fichiers Markdown avec illustrations jointes. Nous avons aussi besoin de gens pour vérifier et corriger la production de ces fichiers Markdown, améliorer la qualité des illustrations et créer des scripts d’automatisation.
- Vous vous y connaissez un peu ? Il faut mettre à jour les contenus, ajouter les dernières découvertes, documenter les améliorations des navigateurs, enrichir le contenu, et compléter les chapitres manquants.
Pour l’heure c’est assez simple : Si vous voulez améliorer l’existant il suffit de faire un fork sous github, modifier ce qui vous semble à changer et envoyer une pull request. L’investissement est quasi nul.
Si vous voulez aider à compléter l’existant le mieux est de m’écrire ou commenter ci-dessous avec le temps dont vous disposez pour que je vous envoie une partie du document source. Pour référence j’ai fait le chapitre 1 en environ 3 heures, mais rien n’interdit de prendre une partie plus petite. L’idée est de faire des aller-retour sur 2 à 3 jours tout au plus, en préférant beaucoup de petits pas à un très gros. Même une heure de travail permet de faire avancer les choses.
-
Prison dorée, ce n’est que le début : mac os x
Hier j’ai été « bloqué » par une application Mac qui refusait de se lancer. L’appli ne vient pas de l’app store et n’était pas signée => refus du Mac.
Tous les geeks m’ont répondu « il y a une option de configuration dans les préférences système, onglet sécurité » pour réautoriser les applications non validées par Apple. C’est à mon avis passer totalement à côté du problème. L’option de configuration, la plupart des gens n’iront pas la trouver, n’oseront pas la toucher, ou simplement sortiront avec un « installer cette application c’est compliqué ».
On est simplement en train de créer des applications de première classe, validées, mises en avant, et des applications de seconde ou troisième classe, autorisées uniquement explicitement en allant tripatouiller les préférences systèmes.
Vous ne me croyez pas ? Moins de 24 h après je tombe sur un article où l’auteur a tenté une installation d’un logiciel largement diffusé et échoué à cause de la restriction « app store ». Non, il n’a pas tripatouillé les configurations, il est passé au logiciel concurrent (lire le paragraphe juste sous la première illustration) :
Le temps de ces réflexions, le logiciel Kobo est téléchargé, en version Mac, mais une mauvaise surprise nous attend après l’installation. Apple refuse d’ouvrir l’application, parce qu’elle n’a pas été téléchargée depuis l’App Store, et à ce titre, la machine ne pourra pas la lancer. Rien à voir avec Fnac, Kobo, ni l’éditeur, se dit-on, mais tout de même… Direction l’App Store, pour tenter de poursuivre, et nouveaux déboires : pas d’application Kobo. Fin des opérations de ce côté. De quoi commencer à perdre patience, une fois encore. De son côté, ADE a correctement fait son travail, et ouvert notre lien de téléchargement sans peine. Et le document est ouvert.
Nombre d’applications vont passer par l’app store, et leurs auteurs ont bien raison, mais ça ne fera qu’augmenter le fossé entre les deux classes d’application, isolant encore plus celles qui n’y sont pas.
Le danger c’est que cela donne un pouvoir immense à celui qui contrôle l’app store et qu’Apple, et que la pomme pose des conditions franchement non neutres. Il est tout à fait possible que l’application dont parle l’article n’ait pas le droit d’être vendue sur l’app store sans retirer plusieurs fonctions, dont tout ce qui est vente en direct.
Alors oui, « yaka changer la configuration », et quand notre liberté sera de ne diffuser que des applications validées et conformes aux intérêts commerciaux d’Apple ou de subir une mise au banc avec procédure d’installation complexe et étiquette « application tierce je-serais-vous-je-n-y-toucherais-pas », il sera trop tard.
-
Livre en rédaction communautaire – Licence
Les conditions et licences du livre que je compte relâcher sont en pleine réflexion. Je suis preneur de vos avis et de vos commentaires, tout peut changer en fonction des différents retours.
Pour faire court, le principal
Ce billet est long, afin d’expliquer mes choix et permettre d’avoir des retours argumentés sur des points précis plutôt que des opinions générales. Pour ceux qui ne liront pas tout :
Je considère que le livre appartient à ses auteurs et contributeurs. C’est à ceux qui contribuent que revient(dra) le choix des conditions de diffusion.
Un des modèles possibles est de leur réserver les usages commerciaux ou sous forme de livre, soit pour une durée fixe soit le temps de recueillir une certaine somme comme rétribution du temps passé.
Ce n’est pas le seul modèle et il est aussi tout à fait possible que le choix se porte sur une licence libre, mais il serait prématuré de faire un tel choix avant que le contenu ne soit mature et que les contributeurs principaux aient rejoint le projet.
En plus des raisons exposées précédemment, l’objectif principal – et unique le temps que le contenu ait atteint un stade mature – est de voir le livre enrichi et complété pour en faire une œuvre complète qui ait un sens – ce qu’elle n’est pas dans son état inachevé actuel.
Ainsi, les droits accordés le sont pour l’instant avec l’unique objectif de permettre le travail collaboratif, à l’exclusion de tout autre usage. Le reste sera décidé plus tard.
Brouillon de conditions de réutilisation
Tous les usages sont autorisés s’ils sont à titre privé et individuel, sans rediffusion ni partage.
La redistribution ou la diffusion du contenu verbatim ou modifié, ainsi que les travaux dérivés, sont autorisés aux conditions cumulatives suivantes :
- Conservation du cartouche d’information mis à jour et mis en avant de façon claire, évidente et visible pour le lecteur et le contributeur
- Se faire sous la même forme et architecture que l’œuvre d’origine (pas de conversion vers un autre format ou un autre support par exemple)
- Ne pas avoir pour objet ou intention de remplacer l’œuvre d’origine
- Se faire sous les mêmes exactes conditions, qui ne peuvent être plus restrictives
- Ne pas se faire à titre commercial ou publicitaire
- Donner au groupe mainteneur du contenu d’origine un droit non exclusif et délégable de représentation, d’adaptation, de traduction, d’exploitation, de diffusion, et d’utilisation, totale ou partielle, à titre commercial ou non, sur tout support (dont en particulier : support numérique, papier, vidéo et audio – ce qui inclut entre autres les livres, revues, articles, présentations, mémos, dépliants et affiches sous formes papier, fichier numérique, disque, bande, et streaming), dans le monde entier et pour la durée maximale prévue par le droit d’auteur, sur les modifications et travaux dérivés ainsi diffusés ainsi que sur les produits dérivés qui pourraient en découler.
Est considéré comme travail dérivé tout contenu incluant tout ou partie du contenu d’origine ou/et qui ne peut être raisonnablement considéré comme indépendant de ce contenu d’origine.
L’acceptation de ces conditions n’est pas requise mais sans ces conditions et leur acceptation, vous n’avez aucun droit d’utilisation et encore moins de diffusion sur le contenu.
La distribution du contenu protégé ou d’une œuvre dérivée en ayant connaissance des présentes conditions est considéré comme une acceptation des présentes conditions et en particulier de la cession d’une licence non exclusive sur le contenu diffusé, tel que prévu au point 6.
Le cartouche d’information
Il reste à faire mais inclura les éléments suivants :
- Le titre et l’adresse – avec un lien – du contenu d’origine
- La mention de tous les auteurs significatifs de l’œuvre d’origine
- S’il s’agit d’un contenu modifié ou d’une œuvre dérivée :
- La mention explicite que le contenu a été modifié et de quel contenu il dérive – avec un lien ou à défaut les coordonnées les plus complètes possibles
- Au choix de la personne qui distribue, pour l’imposer aux suivants s’il le souhaite, la mention de tous les auteurs significatifs de l’œuvre modifiée ou dérivée
- Les conditions d’usage et de redistribution
- La date de dernière modification du contenu
Notion d’auteur significatif et répartition des usages commerciaux
Mon objectif est que les usages commerciaux pour l’instant réservés bénéficient à tous les auteurs. Il peut toutefois être difficile et inutilement complexe de prendre en compte des dizaines ou des centaines de contributions unitaires réduites à des corrections de typographie. Surtout, il sera impossible de prendre une quelconque décision d’ouverture sous licence libre s’il faut obtenir l’accord de plus qu’un groupe restreint.
J’envisage donc de considérer un groupe d’auteurs « significatifs », c’est à dire étant à l’origine d’au moins 10 % du travail réalisé sur l’œuvre. C’est à ce groupe que sont donnés les droits dans le cadre des conditions de réutilisation et que sont réservés les usages commerciaux éventuels. Les décisions et redistributions pécuniaires éventuelles peuvent être faites au pro-rata de la participation.
Tout ça est à discuter
Tout ce qui précède est à discuter, rien n’est fixé et tout peut changer du tout au tout en fonction de vos commentaires. Toutefois, la voix de ceux qui comptent effectivement contribuer et si possible significativement seront les seules qui auront une forte influence.
-
Livre webperf, appel aux bonnes volontés
Il est temps de faire le deuil de la forme du projet initial. J’ai commencé à écrire un livre technique sur les temps de réponses des sites web il y a maintenant quelques années.
Un livre ça prend du temps
Suite à des changements professionnels et personnels successifs j’ai eu de moins en moins de temps à y accorder et la rédaction plafonne irrémédiablement à 50%. Ces derniers temps je considère même que ce taux de 50% est en chute libre car le contenu vieillit en regard des capacités actuelles des navigateurs et en regard de l’état de l’art. Voir mourir ce contenu dans lequel j’ai tant investit me semble trop difficile.
J’ai tenté d’y investir un peu plus de temps, de me faire accompagner par un auteur secondaire, de co-écrire, ou même de donner ce contenu à un auteur qui pourrait prendre la suite mais à chaque fois il est évident que le travail est énorme et que peu de gens sont à la fois suffisamment experts et avec assez de temps libre.
Un projet communautaire ce n’est pas magique
Je crois pas vraiment à l’idée qu’il suffise de relâcher le contenu dans la communauté pour qu’il soit magiquement mis à jour et enrichi. Cela peut fonctionner le premier mois mais ensuite cela demande un réel investissement avec des relecteurs, des gens pour animer, pour coordonner, et surtout de vraies bonnes volontés pour contribuer plusieurs heures.
« L’effet Wikipedia » n’est pas si courant. On compte plus de projets délaissés que de projets maintenus activement et même côté webperf il y a eu des expériences malheureuses en anglais. Relâcher son bébé dans la nature est toujours difficile mais si c’est pour le voir mourir en public c’est encore plus frustrant.
Essayons, le travail à faire
Ceci étant dit, ça vaut le coup d’essayer. L’objectif à court terme c’est extraire et convertir le contenu provenant d’un traitement de texte vers un format adapté pour un travail à plusieurs, probablement du Markdown ou équivalent, avec des fichiers par chapitre ou sous-chapitre. Les images doivent être extraites, taillées, et organisées de façon cohérente. Ensuite, une fois sous github, on pourra voir qui se sent de travailler.
Un autre billet suivra sur la question des droits d’auteurs et de la licence, ça mérite plus qu’un paragraphe. Entre temps je cherche des gens que ça intéresse suffisamment pour envisager d’aider à cette première étape d’extraction et conversion. Il s’agit d’un vrai travail, qui prendra du temps et qui nécessitera des traitements manuels. Ne vous proposez pas si c’est juste pour penser « ouais c’est génial » sans arriver à dégager des heures de temps libre sur le sujet.
-
Cherche routeur
Je cherche un petit routeur. Avant de répondre avec vos choix habituels, voici mon besoin :
- J’ai besoin de deux ports ethernet qui redirigeront vers du WAN, le reste vers du LAN. Préférablement plus de deux ports LAN mais ce n’est pas primordial.
- Ces deux ports diffusent actuellement des annonces DHCP. Je ne suis pas certain de pouvoir couper les deux donc il faut que le routeur puisse filtrer ces annonces pour ne pas les laisser diffuser sur le reste du réseau.
- De la part des ports ethernet locaux, certains accès doivent être routés préférablement vers un port WAN ou un autre suivant la plage IP:port destination (et si possible en fonction de l’IP source, mais ce n’est pas nécessaire)
- J’aimerai un fail-over : quand la connexion semble HS sur un des ports WAN, que les accès soient alors tous routés vers l’autre port WAN
- Sur les ports locaux il me faudrait au moins deux réseaux distincts qui ne puissent pas communiquer entre eux
Ce peut être un petit routeur matériel, ou un boitier linux pas cher sur lequel faire tourner une distribution bsd ou linux dédiée que vous connaissez. Je suis ouvert à tout.
Je trouve des choses, mais à des prix plus élevés que mon budget. Que connaissez-vous qui puisse répondre à ce besoin sans avoir des prix monstrueux ?
-
X-UA-Compatible : IE=Edge
Je rage devant tous ces afficionados qui veulent être à la pointe et qui tout en crachant sur les mode de compatibilité et doctype switching, forcent les futurs navigateurs à reproduire les mêmes problèmes.
N’utilisez pas « X-UA-Compatible : IE=Edge ». C’est inutile et contre-productif.
Un pari risqué sur l’avenir
Avec cette entête, on déclare explicitement une compatibilité avec tout moteur Internet Explorer futur. Celui de dans deux ans ou celui de dans cinq ans.
Avec le passé des navigateurs, l’histoire du doctype switching, les modes de compatibilité et les ruptures de compatibilité diverses, c’est quand même un pari qui semble perdu d’avance.
La question n’est pas tellement de savoir si vous codez « standard », mais que le standard peut évoluer ou se préciser, que certaines fonctionnalités peuvent être abandonnées, ou que certains bugs peuvent être corrigés en introduisant des effets de bords sur vos pages. Même ceux qui codent « standard » jusqu’au bout des ongles choisissent en général tel ou tel montage pour contourner les manques ou différences des navigateurs et que ces manques et différences évoluent avec le temps.
Le problème n’est pas vos pages ou votre code, c’est l’environnement autour.
Et encore, je laisse de côté ceux qui s’attachent tellement fort aux standards qu’ils finissent pas n’utiliser que des fonctionnalités avant leur stabilisation voire avec préfixées dans des versions de test. Eux *vont* des problèmes, mais ils le méritent.
… (le plus souvent) inutile
Le système est fait pour trois cas :
- Permettre à un site codé pour une ancienne version d’Internet Explorer et non compatible avec les suivantes, de bloquer le moteur de rendu à cette version précise.
- Permettre à un intranet ou à un site autrefois liste noire pour incompatibilité historique, après une refonte et en attendant d’être retiré des listes noires, de déclarer pouvoir/vouloir désormais utiliser les versions récentes du moteur d’Internet Explorer.
- Permettre à un site incompatible avec les anciennes versions d’Internet Explorer d’être embarqué via une iframe dans un site non compatible (soit sur liste noire, soit qui demande explicitement une ancienne version du moteur)
Si vous n’êtes pas dans un de ces trois cas, il est très probable que vous n’ayez pas besoin d’une entête X-UA-Compatible. Pour utiliser la dernière version respectueuse des normes du moteur d’Internet Explorer, il vous suffit de coder des pages valides avec un doctype correct et sans prologue XML.
Sauf à être dans un des cas précédents, le X-UA-Compatible n’apportera rien de plus à part les effets négatifs qui seront décrits plus haut.
Mais si vous souhaitez quand même un opt-in
Même si vous vous retrouvez dans un des trois cas décrits plus haut, ou si vous souhaitez quand même être explicite, se déclarer explicitement compatible avec de futures versions qui n’ont même pas commencé à voir le jour est toujours aussi risqué.
Vous avez testé avec IE10 ? alors déclarez IE=10. Vous n’aurez rien de moins que prévu, même si un IE11 ou un IE12 sortent. Si ces prochains n’introduisent pas de problème de compatibilité, il est probable que vous bénéficierez de toutes façons du nouveau moteur. À l’inverse, s’il y a rupture de compatibilité majeure, vous aurez probablement moins de problèmes avec un mode de compatibilité « IE=10 » qu’avec un nouveau moteur incompatible « IE=Edge ».
Vous avez tout à gagner à être honnête et à déclarer la compatibilité réelle de vos pages. Au pire le site développé pour IE10 continuera d’être vu avec un moteur compatible avec ce que proposait IE10. Est-ce vraiment si peu souhaitable ?
Si ces pages sont toujours en maintenance active lors d’une nouvelle version du moteur IE *et* que ce moteur est compatible avec la version précédente *et* pourtant qu’il décide de passer en compatibilité quand vous précisez IE=[la_version_précedente] (vous remarquerez que les deux dernières conditions sont assez incohérentes entre elles), alors il vous sera facile de mettre à jour la déclaration. L’avantage c’est que si une de ces hypothèses devient invalide à l’insu de votre plein gré, au moins ça continuera à fonctionner comme avant et comme prévu.
À quoi ça sert alors ?
Le mode IE=Edge est utile à condition que vous testiez toutes les pages différentes à chaque nouvelle beta d’Internet Explorer, et ce tant qu’au moins une de vos pages est en ligne (chez vous ou chez un tiers).
Ça peut être votre cas si vous avez un petit site et que vous avez du temps à y passer. C’est toutefois un pari sur le fait que vous restiez en maintenance active et que vous aurez du temps à perdre à l’avenir. Je ne compte pas le nombre d’applications ou de sites abandonnés qui sont en théorie en maintenance ou dont on pensait qu’ils seraient encore en maintenance.
Le plus souvent IE=Edge c’est surtout pour les sites en développement, et ça devrait y rester cantonné.
Mon problème n’est pas tant que vous choisissiez d’utiliser une déclaration IE=Edge, à vrai dire vous faites ce que bon vous semble et comme je n’utilise pas IE je n’aurai pas à en souffrir. Mon problème c’est quand ça arrive en recommandation ou en bonne pratique à destination des développeurs. Là désolé de vous le dire, mais vous avez fauté. Vous engagez fortement un tiers à quelque chose dont je doute qu’il ait saisi toutes les implications, et ce pour un bénéfice qui reste franchement à démontrer.
Petite pensée pour l’avenir
Si trop de gens utilisent IE=Edge, et qu’Internet Explorer se sent obligé d’introduire une rupture de compatibilité significative, quelle(s) solution(s) leur restera-t-il ?
- Casser la compatibilité, mais ils ont prouvé que dans leur cas spécifique, sachant que leur moteur était fortement utilisé aussi pour les applications natives et pas que le Web, c’était franchement nocif
- Introduire un nouveau mécanisme d’auto-détection bancal comme le doctype switching et complexifier encore plus le développement web qui est déjà bien tordu à ce niveau si on prend en compte tous les modes de compatibilité
- Considérer que IE=Edge correspond en fait à IE=13 (par exemple) et créer un nouveau mot clef pour le remplacer, ou ajouter un suffixe explicite ; ceux qui ont joué avec les User-Agent savent combien ce mode de fonctionnement a ses limites
Même du point de vue du web, en trichant à ce niveau vous n’aidez pas le web à rester à jour, vous risquez surtout de le casser ou de le complexifier. À bon entendeur…
-
Pas de moteur DOM en ruby ? vraiment ?
Je trouve ça tellement étrange qu’à mon avis j’ai simplement des oeillères qui me masquent la bonne librairie de code.
Je cherche un moteur DOM XML utilisable en programmation ruby. J’ai trouvé des moteurs dits DOM-like, c’est à dire des TreeBuilder avec des API plus ou moins heureuses, et dont le parcours est généralement franchement pénible si on n’utilise pas XPath ou qu’on ne recherche pas quelques éléments particulier via leur chemin. Hpricot, Nokogiri, REXML et même libxml font partie de cette catégorie.
Par contre je n’ai trouvé aucun moteur DOM qui cherche vraiment l’implémentation de la spécification DOM. J’attends par exemple un attribut documentElement sur la classe DOMDocument. J’aurai compris sur Ruby avoir un attribut document_element au lieu de documentElement mais là c’est généralement un root que je retrouve. Sur les interfaces pour parcourir le XML les différences sont bien plus profondes et je me retrouve avec des APIs qui sont généralement très différentes.
Certes, je peux me passer de DOM mais ce serait quand même étrange que personne n’ait implémenté en ruby ce standard extrêmement courant. Qu’ai-je manqué ?
-
Signature des applications Android sur Google Play
Je trouve très peu de conseil ou bonnes pratiques. Développeurs Android qui avez de l’expérience là dedans, j’ai besoin de vos lumières.
Pour l’instant j’ai lu Signing you applications. J’ai retenu que toutes les applications doivent être signées, et que pour pouvoir les mettre à jour il faut utiliser exactement le même certificat que l’application d’origine. Pour signer on créé un keystore et un alias.
Une ou plusieurs clefs
La bonne pratique habituelle côté sécurité c’est une clef par destination, application ou usage. Éventuellement une clef globale pour certifier les premières si on a besoin de s’assurer de la paternité de toutes les clefs. Ça militerait pour signer chaque application avec une clef différente et ça permettrait de déléguer la production d’une ou plusieurs applications à un tiers sans devoir lui donner la clef globale.
Le problème c’est que le document sur la doc Android, ainsi que les quelques documents trouvés sur le web à propos de Google Play, conseillent plutôt d’utiliser une clef globale. Le seul gain que j’y vois c’est que les applications pourront communiquer entre elles. Je n’en ai pas besoin pour l’instant mais il est vrai que je ne connais pas le futur.
Alors, une clef par application ou une clef globale ?
Notion de keystore et alias
Tel que je le comprends le keystore n’est qu’un simple entrepôt pour stocker des clefs. Mis à part que lui même peut être protégé par un mot de passe pour éviter de donner trop facilement accès aux clefs privées. Les clefs privés sont en fait ce qui est pointé par les « alias » dans la documentation. On peut donc avoir plusieurs clefs par keystore.
J’en déduis que la notion de keystore n’influe pas du tout sur Google Play. Je peux sortir ma clef d’un keystore, la mettre dans un autre keystore et signer une mise à jour avec. Tant que c’est la même clef, on se moque du keystore. Ai-je bon ?
J’en déduis donc aussi que Google n’a aucune notion de mon keystore et que je peux y ajouter de nouvelles clefs quand je le souhaite pour de nouvelles applications. Je n’ai pas besoin de préparer un keystore avec un jeu de clef qui ne bougera pas et que je ne pourrai pas mettre à jour. Ai-je bon ?
Voilà voilà, j’ai besoin de vos lumières et ayant peu d’éditeurs d’applications dans mon réseau, j’apprécierai beaucoup que vous fassiez suivre mes interrogations à vos propres connaissances.
Comme j’ai eu quelques conseils de gens qui réfléchissent à haute voix mais n’ont eux-même pas essayé ou pas d’expérience dans tout ça : Si vous vous retrouvez dans cette situation, merci de le préciser pour que je fasse le tri entre les retours d’expérience réels et les autres.