A la base je voulais appeller ça serment, du coup c’est logique que ça y ressemble 
L’intension c’est d’avoir un degré d’engagement fort (bien plus que de cliquer sur j’accepte à l’installation d’un logiciel quand il présence sa licence)
On pourrait effectivement le présenter dans le corp de charte comme tu l’indique et dans la checklist sous forme d’engagement, mais ça fait deux formulations différentes pour désigné la même chose, ce qu’on a souhaité évité.
J’aimerais te dire oui mais :
Du coup je te propose d’éditer plutôt ce message Proposition Charte 1.0 - #14 par 1000i100 et on intègrera tes corrections pour le prochain vote
Oui totalement, l’idée est de test artisanalement avec la V1 un mode de scrutin au consenssus mou (en gros, ça passe facilement (corum bas) si tout le monde est d’accord mais ça bloque très vite s’il y a des objections significative non prise en compte, pour autant s’il y a juste quelques réfractaire au changement qui ne justifie pas leur opposition, il y a des chances qu’il reste suffisament peu suivi pour ne pas bloquer l’évolution).
Dès qu’on aura des outils pratiques, si le principe de scrutin au concenssus mou marche bien, on le garde mais on change la procédure poru qu’elle soit plus pratique.
Et si justement on utilise quelquechose du type « runtime upgrade », on vote pour un hash ou une signature, donc impossible de changer la moindre virgule une fois le vote lancé, d’où le fait que pour jouer le jeu, je t’invite à éditer mon commentaire 14 et non le texte de référence.
On a envisagé de ne tenir compte que du dernier vote depuis chaque identité membre pour permettre de changer d’avis, mais ça complexifiait légèrement les explication et le dépouillement, donc on a fait au plus simple, dans l’idée qu’on améliorerais ça quand on aura des outils de vote dédié dans la V2 pour faire ça mieux.
On aurait pu, mais avec les débat sur la suppression des commentaires de transactions ces dernières années, on a préféré ne pas s’appuyer dessus.
Pour moi non, c’est justement quelquechose qui m’a toujours déranger dans la licence.
C’est important pour moi de séparer les responsabilité/intensions :
Pour moi, cette responsabilité ne reviens pas à la charte (ou licence) mais à ce qui est souvent appellé un « white paper ». Et son absence dans le cas de la Ǧ1 est souvent reprochée par les personnes qui viennent découvrir depuis le monde des crypto.
Ceci dit je suis très favorable à ce qu’un white paper soit rédigé pour expliquer la formule du DU et les autres concepts fondamentaux de la Ǧ1 de manière synthétique et aussi compréhensible que possible, et que la charte y fasse référence plutôt que d’avoir une annexe.
Et dans la checklist avoir une question qui vérifie que la personne certifiée sais où trouver le white paper et qu’il décrit les conceptes fondamentaux de la monnaie libre Ǧ1 me semble une bonne idée.
Oui, de même qu’il est régulièrement question de rendre le permis voiture à durée limité, pour vérifier que les personnes sont toujours en mesure de le respecter, et de pouvoir leur transmettre les évolutions quand il y en a.
Dans la licence actuel il est toujours question de « bien connaitre la personne » notion flou interprétable de manière très différente selon la sensibilité de chacun⋅e. Si ma perception de bien connaitre est dangeureusement laxiste et que pour renforcer la fiabilité du système on fait évoluer ça, les question à chaque certification permettent de transmettre les nouveauté aux anciens qui du haut de leur ancienneté peuvent considérer tout savoir et ne pas avoir besoin de se mettre à jour.
Bref, je suis très favorable à l’approche par checklist plutôt que document à lire et accepter. J’en avais parlé pour la première fois au RML12
Un autre aspect pour moi, en faveur de cette aproche, c’est que la charge reviens à la personne qui certifie, soit quelqu’un qui a fait plus de chemin dans l’écosystème Ǧ1 que la personne à certifier, au moins pour la première certification. Du coup, la courbe d’apprentissage me semble plus douce. On a envisagé de mettre moins de questions lors du renouvellement, mais par simplicité nous n’avons pas retenu cette option. Si on met dans une future version la checklist en annexe pour les développeurs, on pourra le ré-envisager.
A chaque avenant à un contrat, il y a besoin de le re-signer.
Si la validation de la charte/licence se faisait en blochain, associée à sa version, on pourrait à chaque évolution de la charte demander sa revalidation par les membres, en présentant ce qui change. ça répondrais à l’aspect mis à jour avec plus de finesse, mais :
Le logiciel n’est pas conforme à la charte, ce qui peut mener la communauté à le déconseiller ou le boycotter, tout comme une personne qui ne respecte pas la charte/licence vera normalement la communauté lui refuser le renouvellement de certification.
Ce n’est pas une conséquence automatique, ça reste au final, les personnnes qui décident comment gérer les situations de non respect de la charte/licence.
Tout à fait d’accord, en l’état nous avons essayer d’avoir un format et, le plus intelligible pour des lecteurices humain⋅es, et suffisament consistant pour être interprétable par du code.
A parament le compromis semble trop technique pour les humains et pas assez pour les dev, donc peutêtre qu’il va falloir revoir la copie de ce coté
Aurais-tu trouvé plus serieux de dire « Le certifié » ?
Personnellement, pour une monnaie ayant comme date anniversaire le 8 mars, et ayant choisi le féminin pour désigner son symbole monétaire, ça me semble cohérente d’adopter du langage inclusif ou du féminin neutre dans ses documents de référence plutôt que de reproduire l’usage popularisé si je ne me trompe au XIXème scièce du « le masculin l’emporte sur le féminin ». Mais je peux concevoir que ni l’idée ni la façon de la mettre en pratique ne fasse l’unanimité. Pour limiter au maximum les clivage que ce sujet pourrait généré, nous avons privilégié les tournures épicène autant que possible, sauf lorsqu’elle alourdissent trop les phrases.
Rajouter personnes entre « La » et « certifiée » passe du féminin neutre à une tournure épicène, je n’y vois pas d’inconvénient dans les phrase qui ne contienne pas déjà le terme personne (pour éviter les tournure trop lourdes).
D’autre part, le racourcie explicite permet d’introduire la notion de tutelle qui me semble utile pour la certification d’enfant ou de personnes agée ou handicapé, bref pour tout les cas ou une personne physique vivante n’est pas autonome pour gérer son compte, mais reste légitime à accéder à sa part de création monétaire.
Si le changement de nom est accepté, ça me semblerait cohérent oui.
Je suis en bonne partie d’accord.
Si ça passe en l’état, selon moi, on aura gagné du temps, si ce n’est pas le cas, ça me semble pertinant de reproposer les changements tel que tu le suggère.
Pour moi, l’idée de proposer la refonte totale est de pouvoir proposer un tout cohérent qui n’est pas un simple ajustement de la version précédente. (un peu comme un logiciel qui change de version majeur, la rétrocompatibilité n’est pas nécessairement assurée) Hors, sans ce coté refonte radical, je voyais difficilement comment sortir du mélange engagement → charte et information → white paper qui cohabitait jusqu’ici maladroitement à mon gout dans la licence.
En outre, proposer la version avec tout les changement d’un coup, nous permet d’avoir des retours sur l’ensemble des aspects, et vu qu’il y a la charte forgeron et celle du comité technique sur le feu pour la V2, ces retours me semble plus que bienvenue pour les intégrer au plus tôt dans ces autres documents pour qu’ils soient prêts au lancement.
@Moul , Ais-je répondu à toutes tes questions ?
Quand je propose cette formulation c’est en fait parce que
1/ la charte, aussi longue soit elle, ne sera pas plus ou mieux lue que la licence actuelle, elle risque même d’être rébarbative.
2/ cette formulation ou une autre de quelques lignes pour préciser l’importance de ces 2 principes, serait suffisant pour que cela reste en mémoire lors de toute certification
3/ ce serait en complément des questions qui permettent de vérifier si les règles de la TDC ont bien été transmises et comprises.
Cela n’enlève pas le bien fondé de cette charte qui doit exister et être consultable au même titre que les règles de la TDC et la TRM, mais pas en tant que serment qui, pour moi, relève de l’ancien monde et non de la Confiance que la Toile est sensée représenter.
Pour moi le titre À destination des devs devrait être avant La checklist de certification.
Ce pavé de questions est plutôt indigeste à parcourir et vraiment pas destiné à m’expliquer quoi que ce soit en tant que novice. TL;DR. Par contre est très utile en tant que développeur.
Le pavé de questions devrait être rédigé sous une forme normale de prose claire et explicative. Pas trop longue.
Faire en sorte que chaque personne physique n’ait qu’un seul compte membre actif.
Pourquoi le terme seul disparaît dans la phrase clef fondamentale ? J’aimerais plutôt lire :
Je m’engage envers la communauté à n’avoir qu’un seul compte membre actif.
Le texte devrait aussi expliquer clairement que les personnes ne respectant pas la charte prennent un énorme risque, celui de ne plus jamais être certifiées, et donc de ne plus jamais pouvoir co-créer de monnaie. Cela entraînera aussi sûrement des effets collatéraux propre aux communautés humaines, comme le bannissement dans les réseaux sociaux, où la mort grise IRL (on rompt toute communication avec la personne).
Je trouve très bon le chapitre sur les modalités de changement de la Charte, mais je les mettrais en annexe. L’idée des annexes aussi est très bonne.
Merci beaucoup pour tout ce travail !
Globalement d’accord avec @Spiranne30 et @vit
D’accord avec @Spiranne30 pour dire que ces deux phrases résument à elles seules toute la quintessence de la TDC …
mais pour moi elles ne ont pas pour autant suffisantes car il manque ce que la licence présice à savoir ;
C’est ce que j’appelais 'cahier des charges à l’usage des devs"
Bien d’accord avec ça et toute las suite du message
Comment s’assurer que… cela doit faire partie de la charte oui. mais à lire à part pour garder l’essentiel en mémoire lors de la certification tout en invitant fortement à lire cette charte pour mieux comprendre et s’informer.
Idem pour expliquer la raison pour laquelle il faut sécuriser la TDC
Oui le fichier de révocation : important à ajouter au moment de la création du compte membre
Trop d’infos tue l’info.
La charte est essentielle mais peut être lue indépendamment du moment de la création du compte membre.
Ce n’est que mon avis.
Bravo les copines et copains pour cet énorme travail si nécessaire, vraiment. Je vais lire tout ça à tête reposée et a priori, je vous fais confiance.
Une question : est-ce que les virements de vote sont aussi un financement participatif pour vous remercier ? Sinon comment l’effectuer ?
C’est beaucoup mieux avec les titres !!!
c’est ce qu’il manquait.
je valide pour ma part.
Peut être enlever les questions checklist dans un un truc à part car effectivement comme dit @Spiranne30 la charte peut être lu après la création (la charte parle essentiellement de certification au moment de devenir membre)…
La répétition des 2 phrases fera que ça rentrera dans la tête 
EDIT par @1000i100 : plutôt vers les comptes perso des 4 membres du groupes de travail cf : Proposition Charte 1.0 - #42 par 1000i100
Hello @AnAmbles tu peux remercier ici : La caisse de don pour la coordo V2
mmm, 1000i100 a pourtant recueilli une objection majeure sur ce terme :
Donc, effectivement le terme licence n’est pas idéal, mais charte ne l’est pas plus.
« Acte d’engagement : respecter scrupuleusement et transmettre le protocole de certification. »
=> description du protocole.
Tout le reste me paraît superflu, ou bien pas à sa place.
[ l’index des questions - réponse est une bonne idée, mais c’est plutôt une annexe à destination des applis clientes, donc des devs, s’ils veulent l’intégrer dans leur process de certif ; par exemple ]
Je ne peux pas voter pour (et j’ai approximativement 1 page de raisons).
Je ne pas voter contre, car je ne suis pas partisan de maintenir la licence actuelle (qui mérite un petit coup de peigne, éventuellement introduire le terme engagement à la place de licence).
Ce texte ne serait-il pas l’occasion de tester des outils collaboratifs de recherche d’un consensus appliqué un texte ? Et profiter de cette production initiale comme os à ronger pour cette expérience ?
Merci en tous cas pour votre mobilisation sur ce chapitre.
Question bête : qu’en pense Stéphane Laborde (@Galuel) ?
Le seul propos que j’ai vu passé de sa part sur le sujet, c’est que s’il fallait changer qqch à cette licence, ce serait pour la réduire … mais c’était il y a un moment ;-).
Pour moi c’est la confirmation de la création de l’identité (+adhésion en V1) qui vaut adhésion à la Charte. Ce qui me paraît cohérent, car cela donne une raison valable et factuelle, exprimée dans la Charte de motiver un refus de certification.
« Je refuse de te certifier car tu ne respectes pas les engagements de la Charte auxquels tu as adhéré par la création de ton identité dans la toile de confiance. »
Le but de la Charte, pour moi, c’est de donner une raison argumentée à un refus de certification.
Un peu comme :
Je refuse d’aller me battre pour soutenir une politique d’expansion territoriale dont je ne reconnais pas la légitimité.
Simon Astier, Kaamelott, Livre I, 39 : Le Cas Yvain, écrit par Alexandre Astier.
Comme je le répondais à @Moul plus haut, pour moi, la licence mélange plusieurs rôles et je ne trouve pas ce mélange heureux :
Qu’on l’appel licence, charte ou engagement, le moment ou ce document interviens dans le parcours d’un membre me semble mettre au centre le rôle d’engagement.
Pour que cet engagement soit le plus possible identifié en tant que tel et pris au serieur, il me semble pertinant de s’en tenir à ce rôle, et d’épurer le document de toutes autres fonctions.
Ces autres fonctions n’en sont pas moins essentielles, mais là encore, pour qu’elles puissent être pleinement intégrées, elles méritent selon moi des documents dédiés.
Ce 3ème rôle me semble en partie endossé par la checklist que nous proposons dans la charte 1.0, ce qui constitue donc malgré tout un cumule de fonction entre engagement et recommandation (ce qui se traduit aussi par le fait que certaines questions soit engageante et éliminatoire et que d’autres soient pédagogique et facultative). Est-ce LA bonne réponse pour répondre à cet enjeu ?
Je n’ai pas la prétention de dire que oui, mais j’ai l’espoir que ça complète de manière pertinante les recommandations sur le forum, les vidéo explicatives, les recommandation orales lors des rencontres…
Ceci dit, effectivement, la vocation de certaines des questions étant d’avantage pédagogique qu’engageante, ça corroborre les retours pronant de déplacer la checklist en annexe pour les développeurs.
J’en viens à proprement parler aux 3 points que tu cite.
Tu n’a pas utilisé le terme « bien connaitre » mais c’est un sujet dont nous avons beaucoup discuté.
Trops flou dans ses possibles interprétations, nous avons cherché comment nous en débarasser en identifiant quelles intensions cette consigne un-mesurable visaient, c’est entre autre ce qui nous a mené aux engagements fondamentaux de la charte. Les autres intensions (garantir de pouvoir repéré un double compte) reste une intension louable mais dont la réalisation est impossible à garantir, nous avons mis beaucoup de vigileance à ne demander que des choses réalisable. Si l’on veut construire une confiance fiable, faire prendre des engagements intenable nous a sembler une très mauvaise base, donc nous évitons cela à tout prix.
En revanche, certaines bonne pratiques peuvent augmenter les chances de ce rendre compte d’un double compte s’il à lieu, ce que nous avons donc repris dans la checklist : être en mesure de contacter efficacement ses certifié⋅es, connaitres d’autres personnesl l’ayant certifié⋅e.
Je me sentiriais probablement davantage compris dans un monde ou chaque personne s’intéresse et comprends les fonctionnements informatiques réseaux, décentralisé, de blockchain et de cryptographie assimétrique… Mais si l’on veut une monnaie qui s’adresse à toutes et à tous, pas uniquement à des techniciens, assurer un accès sécure à chacun⋅e est un travail qui reviens au dev et aux choix d’ergonomie et de sécurité qu’iels font dans leur logiciel avant tout. Devoir former l’ensemble de la communauté à utiliser des mots de passes fort et à ne pas les oublier, et gérer correctement un document de révocation… Me semble un espoir vain.
Mettre de l’énergie à former à la sécurité informatique me semble toujours une bonne idée, mais faire reposer la sécurité d’un écosystème grand public dessus me semble succidaire d’un point de vue sécurité justement.
Y répondre par une conception pertinante des logiciel me semble plus plus pertinant. Ce que font Gecko, Ginkgo ou CesiumV2 pour la création de nouveau compte (générer une clef aléatoire et la stocker, sans compter sur l’utilisateur pour la retenir ou pour la choisir).
Idem, et je ne vais peutêtre pas me faire des amis en disant ça, l’importance donné au document de révocation me semble absurde au regard du modèle de menace :
Soit lae membre sais conserver des secrets et saura retrouver l’accès à son compte, tout comme son document de révocation (qu’iel peux aussi bien stocker que générer à la demande, bien plus tard, le jour ou son usage deviendrais utile (piratage/vol de compte), puisque justement ce membre sais garder des secrets (donc également l’accès à son compte, pas uniquement son fichier de révocation))
Soit lae membre a une tendance aux oublis, et minces me semble les chances qu’iel se rappelle :
Plutôt que de se souvenir de ses accès qu’iel utilise à chaque connexion (aussi fréquentes ou rares soient-elles), qui lui permettent de générer ce document de révocation le moment venu où sont usage est requis.
Pour moi, les recommandations autour du fichier de révocations représente une greffe d’un outil de techniciens pour des techniciens (outil très utile dans son contexte soit dit en passant), transplanté pour un public non technicien sans en repenser l’utilisabilité. En tant que choix de jeunesse, je peux comprendre, mais continuer à s’accrocher au stockage religieux de ce fichier des années à l’avance ne fait pas sens pour moi au regard de la communauté actuelle et de sa diversité de profil (et de maitrise de l’informatique). Alors que pouvoir révoquer son compte fait clairement sens pour moi, par fichier de révocation en option pour les tech, mais par clic dans l’interface une fois connecté à son compte avant tout !
Si je peux conserver mon fichier de révocation, je peux conserver l’accès à mon compte, ça repose sur les même compétences. Si vous avez des contres exemples en quantité suffisante pour contrebalancer les personnes qui n’on pas pu révoquer leur compte ayant perdu trace de leur fichier de révocation bien avant de perdre leurs accès, ou qui n’ont jamais compris l’intéret de révoquer, je veux bien rester ouvert à changer d’avis.
Et ça tombe bien avec l’arrivé de la V2, on à l’occasion de gérer mieux ces choses là, autant mettre à jour le discours et pas uniquement les outils pour porter de l’importance là où il y a besoin d’en mettre plutôt que de complexifier innutilement le parcours de découverte des nouvelleaux.
Désolé, sur le focus « document de révocation » c’est plus de 5 ans de frustration qui sortent.
Je sens qu’on va encore avoir de chouettes discussions
Pour moi, c’est déjà un test d’outil de consensus que le système de vote pour adoption qu’on test actuellement.
S’il n’y a pas de nouveau votes, avec actuellement 20 pour et 3 contre, la charte sera refusée, ce que mènera tout naturellement à tenter une 2nd proposition essayant d’être plus consensuelle en tenant compte des objections faites.
Même si théoriquement consensus et votes sont des approches distinctes, ce que je vise ici, c’est d’avoir un processus décisionnel actant d’un consensus. Un consensus moue tout du moins.
En effet, (je crois en avoir déjà parlé mais je ne retrouve plus où), pour moi, il y a 3 types d’opposition à une proposition de changement :
Un consensus mou se doit d’adresser les 2 premiers types pour êtes atteint, mais doit pouvoir être atteint sans adresser le 3ème type.
Dans un temps présentiel destiné à construire un consensus sur un sujet, la pression social permet de faire accoucher quelqu’un qui peine à dire le pourquoi de ses réticences, ou à ce qu’il se joigne à l’avis majorité en retirant son/ses objections ou à ce qu’il quitte le projet.
Dans notre contexte, je ne vois pas comment compter sur une forme saine de pression sociale applicable à la temporalité d’une prise de décision.
Il me semble donc essentiel de pouvoir s’accomoder de quelques oppositions (considéré comme essentiellement de principe) sans que ça ne bloque l’adoption d’un changement. C’est cette tolérence, faible, à des oppositions non résolues qui m’amène à nomer consusus « mou » le mode de vote pour adoption testé ici.
Je me réjouis de lire ça 
Et ta page de raison m’intéresse, plus particulièrement pour celle qui n’ont pas été mentionnées par d’autres
J’avais retenu de notre discussion les risques d’aller sur un terrain morale, notament coté commité technique, (sans forcément voir comment créer des garde-fou qui n’aille pas du tout sur ce terrain), mais je n’avais pas fait de lien fort avec le terme « charte »
Engagement me semble correspondre parfaitement coté sens, en revanche, je n’ai jamais croisé de document intitulé « engagement » c’est une maigre objection, mais je pourais avoir peur que le terme soit plus perturbant pour les habitudes que celui de « charte » (mais si nous n’avons pas retenue l’objection, « perturber les habitudes » pour un passage de « licence » à « charte », ça ne me semble pas plus faire sens de la retenir entre « licence/charte » et « engagement ».
Nous ne l’avons pas pensée de cette manière, du coup ça serait plutôt en envoyant 1 don à chacun de nos comptes perso (trouvable facilement : nous sommes les 4 premiers votant pour la charte 1.0).
Même si nous avons discuté charte aux dernière rencontres de coordo V2 et que nous créons une commission charte V2 notament pour travailler sur les chartes forgeron et comité technique,
même si, si je ne me trompe @Maaltir @Natha @pini et moi même on pris pars à la coordo V2 au moins ponctuellement, le groupe qui à produit cette charte n’est pas la coordo V2, donc même si j’encourage à faire des dons à cette dernière, ça ne me semble pas le bon aiguillage dans la situation actuelle
Oui vrai .
non non, côté Comité technique, le registre n’a rien de moral, le problème est plutôt posé en termes de « loi dynamique » :
La décision on-chain du runtime uprade génère un défi de décentralisation - nouveau - à cet endroit spécifique, or le Comité technique est une structure qui cristallise une centralisation et qui l’institue. Cette option ne remporte pas le défi. Ce qu’elle annonce est davantage la reproduction des motifs familiers, avec des débats sur les votes et les représentativités. Puis un organe en appellera un autre. On repart comme en 40. A développer bien sûr.
J’en retiens que ça vaut le coup de chercher d’autres pistes. Creuser celle des protocoles, avec une approche plus algorithmique que statutaire est par exemple une option qui me parait intéressante et fertile.
Le registre moral concernait bien le mot Charte, or je partageais avec toi mon analyse sur la peine que représenterait une telle quête collective.
Mon sentiment est qu’elle est vaine, voire nuisible dans le sens où elle ne peut générer que des clivages (car nous ne savons guère gérer les polarités autrement, culturellement). Il y aura donc toujours des postures viscérales réfractaires, chargées d’émotions pas fatalement cohérentes, mais elles seront de ce fait légitimes.
Une morale commune ne peut être qu’imposée, et une morale ne peut être imposée qu’avec une armée et une religion. L’image est transposable à petite échelle de façon fractale. Religion qui en trouvera toujours une autre pour s’y opposer, ou la créera, support historique de tout un tas de bains de sang, bien encore présents.
J’en retiens que ce chemin là n’est pas de bon augure.
→ Plutôt réserver ce registre à ma sphère la plus intime (toutes les personnes qui me font cheminer, philo, spirituel).
→ Plutôt me concentrer sur une échelle plus large, mon bassin de vie et les suivantes, donc sur les aspects économiques et génériques de notre façon de fonctionner. Notre façon de produire et distribuer, notre façon de prendre des décisions.
La confiance de la toile de confiance ne qualifie pas la confiance que je fais aux personnes que je certifie, ni que je les aime ou qu’elles pensent comme moi. Une certification ne dit pas « on peut - vous pouvez - faire confiance à cette personne ». [ mais rien n’empêche de concevoir un gestionnaire de confiance qui ajouterait de telles dimensions ]
Ici, confiance désigne la nécessité fiduciaire de toute création monétaire. Or ici, elle repose sur la réciprocité de 2 choses :
C’est ça que l’on garantit à toute la toile en certifiant quelqu’un. C’est à ça que l’on s’engage lorsqu’on se fait certifier. Point.
Cet acte d’engagement est de fait l’unique relation contractuelle de notre toile de confiance.
L’enjeu est précieux : c’est cette décentralisation fiduciaire humaine qui structure l’intégrité de notre identité numérique, autrement que par une autorité centrale ou par une capture biométrique. Elle passe par les individus et leur réseautage organique.
La « règle de distance » régit la qualité de cette toile en terme de « densité du tissage ».
Tout ça est juste, comment dire, … super classe. Ça inspire le respect, ça ne nécessite pas requérir une charte et son adhésion, mais ça mérite de « chercher la qualité » dans son propre protocole perso de certification (il doit garantir simplement les 2 choses réciproques, et la transmission de cette réciprocité).
non ?
RQ sémantique pour les amateurs. « Toile fiduciaire » serait sans doute plus approprié, le terme plus froid et technique éviterait pas mal d’amalgames pas toujours fructueux. haha j’entends déjà des cris de panique à cette suggestion.
PS : je peux poster ici une seconde option d’os à ronger ? une version « réduction de balsamique proche d’un caramel » ou « distillation concentrée d’une huile essentielle » ? ou bien ça fout le bordel dans votre process…
PS2 :
