Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2023-04-14T09:48:37+02:00Les derniers messages parus sur le forum de Zeste de Savoir.De l'adoption de bonnes pratiques de développement en entreprise, message #2499372023-04-14T09:48:37+02:00zhou2019123/@zhou2019123https://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p249937<p><a href="https://www.lanavape.com">https://www.lanavape.com</a></p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362652021-07-24T20:27:59+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236265<blockquote>
<p>Je pense que ça peut être intéressant d’appuyer ces aspects, et de sortir des études qui montrent ces couts financiers.</p>
</blockquote>
<p>Je viens de tomber sur <a href="https://codescene.com/technical-debt/whitepaper/calculate-business-costs-of-technical-debt.pdf">cet article récent</a> qui cite en intro une estimation assez lourde : le développeur moyen perd entre 23 et 42% de son temps à cause de la dette technique. Puis il explique la même chose que toi (en général les boites ne se rendent pas compte de ce coût) et propose une méthode de calcul de la dette technique. Il me reste encore à le dépiauter mais ca semble une source prometteuse.</p>
<p>Edit: Hmm en fait c’est un article qui fait la promo d’un soft, les remarques sont intéressantes mais je vais plutôt creuser du côté de ses sources.</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362562021-07-23T17:15:30+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236256<p>Je pense qu’il est aussi bon de préciser que dans un monde idéal, le manager n’aurait <strong>pas son mot à dire</strong> sur ces pratiques.</p>
<p>Son boulot c’est de s’assurer que les fonctionnalités désirées (le <em>quoi</em>) sortent en temps et en heure, le <em>comment</em> ne devrait pas être son problème, mais le devenir <em>si la qualité n’était pas au rendez-vous</em> : c’est justement quelque chose qu’il devrait déléguer à l’équipe de dev, tant que le résultat est là.</p>
<p><strong>Cependant</strong>, si on en est là aujourd’hui, c’est parce que certaines équipes de devs continuent à ressentir le besoin de demander la permission, pour plein de raisons possibles (absence de seniors, micromanagement, produit en difficulté — parfois, ironiquement, à cause de la dette technique —…).</p>
<p>Il me semble que ce serait pas mal, donc, de nuancer en disant que le but de l’article n’est pas non plus que le manager se mette à imposer toutes les bonnes pratiques qui seront mentionnées à son équipe, mais plutôt de rétablir une relation de collaboration saine et de confiance : c’est <em>aussi</em> aux équipes de dev de prendre ce pouvoir de décision qui est censé être le leur, particulièrement quand ils bossent selon une méthodologie Agile, et c’est aussi aux devs d’adopter les pratiques avec lesquelles ils sont à l’aise, pas forcément toutes, ni toutes à la fois.</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362542021-07-23T16:47:24+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236254<p>Et puis surtout, c’est pas des détails qui sont à remonter au client.</p>
<p>Pour moi les seuls cas où le client a son mot à dire là-dedans, c’est :</p>
<ol>
<li>En cas de normes qualité ISO-machin spécifiques, ou</li>
<li>S’il est directement impliqué dans le processus de développement (ça peut arriver avec certaines méthodes agiles) </li>
</ol>De l'adoption de bonnes pratiques de développement en entreprise, message #2362532021-07-23T16:34:44+02:00viki53/@viki53https://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236253<p>Se cacher derrière l’ignorance du client pour ne pas mettre en place des process qualité c’est vache… </p>
<p>C’est pas parce que je sais pas comment un moteur de voiture fonctionne en détails que j’ai pas envie qu’il y ait des tests en amont pour qu’il explose pas en route.</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362492021-07-23T13:47:25+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236249<blockquote>
<p>J’ai un exemple un peu particulier puisque cette objection contre la mise en place de tests m’a été adressée par un manager technique qui lui-même codait encore : « le client ne comprend pas tout ça, il s’en fiche de savoir qu’on a 90 % de code coverage. Il ne paiera pas plus cher pour ça. »</p>
</blockquote>
<p>Oui le client ne sait pas ce qu’est le coverage, pas plus qu’il ne sait ce qu’est un thread ou une gateway. Par contre le client sait ce que c’est qu’un bug ou une panne, et le coverage est un outil qui permet de contrôler, dans une certaine mesure, la fréquence à laquelle ceux-ci vont se produire sous ses yeux (idéalement on la veut nulle).</p>
<p>Sur le coverage je pense qu’il faut également que l’on mentionne que ce n’est <strong>pas</strong> un KPI. Écrire des tests juste pour "faire du coverage" est un énorme piège, et une perte de temps. C’est simplement un indicateur : s’il est inférieur à 90% alors les tests ne couvrent pas assez le code, donc il reste trop de zones d’ombre. S’il est supérieur ou égal à 90% (ou même égal à 100%), alors les tests couvrent suffisamment le code <em>mais</em> ça ne suffit pas encore pour avoir confiance.</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362452021-07-23T08:22:08+02:00sgble/@sgblehttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236245<p>J’ai un exemple un peu particulier puisque cette objection contre la mise en place de tests m’a été adressée par un manager technique qui lui-même codait encore : « le client ne comprend pas tout ça, il s’en fiche de savoir qu’on a 90 % de <em>code coverage</em>. Il ne paiera pas plus cher pour ça. »</p>
<p>Certes, le client ne comprendra peut-être pas <em>code coverage</em>, mais je suis sûr qu’il comprend et sera heureux d’entendre que son produit est testé, nous permettant par là-même de lui offrir des garanties concrètes quant au risque que les mise à jour successives cassent des fonctionnalités indispensables, impliquant le chômage technique jusqu’à résolution. (« Résolution » = <em>hot fix</em> en prod)</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362432021-07-22T23:49:36+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236243<p>L’idée vient de me traverser l’esprit que si l’article se veut convaincant, alors il va aussi nous appartenir de donner les conditions réelles et parfaitement valables dans lesquelles l’adoption de telle pratique ou tel outil n’aura que peu de chances d’être rentable ou d’avoir un impact positif mesurable. </p>
<p>De mon côté, je me suis plutôt retrouvé confronté à des cas classiques.</p>
<ul>
<li>"On n’a pas le temps de bien faire, ça doit être fait pour la semaine prochaine" (puis à la release, on se retrouve avec une prod qui ne fonctionne pas, donc une grosse interruption a posteriori, où l’on doit corriger la prod à chaud pour éteindre le feu, puis implémenter la "bonne" solution, mais cette fois dans l’urgence et/ou en heures supplémentaires pour stabiliser la prod).</li>
<li>"Le TDD est une perte de temps parce que cela revient à écrire deux fois plus de code" (sauf que taper du code sur un clavier n’est pas le goulot d’étranglement dans le processus de développement, et par ailleurs lorsque l’on récrit plusieurs fois le même code pour le corriger jusqu’à ce qu’il finisse par passer des tests manuels ou répondre au besoin des utilisateurs qui a évolué entre temps, c’est beaucoup plus du double de lignes du code final que l’on finit par taper). I' est possible de trouver dans la littérature des résultats qui montrent que le TDD ne se contente pas de nous faire économiser du temps sur le long terme, mais <strong>dès la première demi-heure.</strong></li>
<li>"Le pair programming utilise deux fois plus de ressources pour le même résultat final, donc c’est du gaspillage" : c’est bien souvent une erreur de calcul, car le pair programming consiste simplement à réaliser le code review au même moment que le code est écrit, et requiert tout autant de ressources que ce dernier, avec pour avantage que cela se fait sans générer d’interruptions ni d’allers-retours fastidieux entre devs (qui finissent d’ailleurs par se mettre à deux devant le code pour discuter plus rapidement et se mettre d’accord pendant la review). Le temps écoulé entre l’écriture de la première ligne et la fin de l’étape de développement est de ce fait divisé par deux. C’est aussi un moyen imparable d’augmenter le bus factor de l’équipe (le nombre de personnes dont le départ est synonyme de perte de connaissances), et de former les développeurs.</li>
</ul>De l'adoption de bonnes pratiques de développement en entreprise, message #2362422021-07-22T22:55:35+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236242<p>Si je ne compte que les arguments que j’ai déjà entendus dans ma vie professionnelle contre la mise en place d’outils ou procédures de développement ou associés.</p>
<p>En fait on peut les regrouper en un petit nombre de catégories d’arguments, mais c’est intéressant d’avoir les arguments exacts parce que ça donne une idée de comment attaquer le problème.</p>
<ol>
<li><strong>La rentabilité de la bonne pratique n’est pas imaginée, pas comprise, ou imaginée seulement à trop long terme</strong>. Je parle ici de rentabilité purement financière directe (achat de licences), en temps de développement, en confort de développement (et donc en équipes qui restent). Ces deux derniers points se traduisant aussi en pertes financières, mais cette traduction peut elle-même être mal comprise.
<ul>
<li><em>« On a pas le temps »</em>. Ça c’est <strong>le</strong> classique, en général sur un projet où la pile de trucs à faire est excessivement plus grande que les ressources affectées au projet, et où donc tout est urgent, donc toute décision qui n’a pas une rentabilité immédiate est ignorée (avec les effets délétères que ça implique).</li>
<li><em>« C’est trop cher »</em> (à peu près tout ce qui nécessite de payer une licence, aussi peu chère soit-elle).</li>
<li><em>« On a déjà essayé et ça n’a pas fonctionné »</em>. Je le met ici, mais ça peut entrer dans les catégories 2 et 3 selon <em>pourquoi</em> ça n’a pas fonctionné : est-ce que la pratique a été correctement mise en place ? Est-ce que les équipes ont été formées ? Ont-elles été impliquées ? Est-ce qu’une rentabilité instantanée a été attendue ?</li>
</ul>
</li>
<li><strong>Le but des outils et méthodes n’est pas compris</strong>. Comme la bonne pratique n’a pas de but réel identifié, on ne peut pas en déduire la rentabilité associée.
<ul>
<li><em>« Ça ne sert à rien »</em>, qui se passe de commentaires.</li>
<li><em>« On a déjà [type de test A], donc on a pas besoin de [type de test B] »</em>. En particulier, l’intérêt des tests unitaires est <em>très</em> mal compris par les personnes qui ne les ont jamais pratiqué.</li>
<li><em>« On a pas besoin de [outil], on a déjà [truc qui en fait n’a rien à voir ou totalement obsolète] »</em>. Extrêmement pénible quand l’interlocuteur commence la réunion en t’expliquant pourquoi en fait tu n’as pas besoin, selon lui, de l’outil, alors qu’il ne sait visiblement pas à quoi ça sert.</li>
</ul>
</li>
<li><strong>La croyance que le projet ou les équipes ne sont pas adaptés à la bonne pratique.</strong> Le décideur reconnaît l’intérêt de l’outil ou de la méthode, mais part du principe que ça ne sera jamais applicable au projet ou à l’équipe. Ça rejoint un peu le point 1 (la rentabilité) mais avec des angles d’attaque très différents. Je fais rentrer <strong>la résistance au changement</strong> dans cette catégorie.
<ul>
<li><em>« La structure du projet ne nous permet pas d’intégrer cette idée »</em>, surtout invoqué sur les projets anciens avec une grosse dette technique, et ça peut être assez vrai – essayez de TU du code spaghetti pour voir.</li>
<li><em>« On a pas le temps de créer tous ces tests »</em>, qui vient souvent avec une croyance qu’il <em>faut</em> immédiatement créer une tétrachiée de tests à la mise en place du framework de test sur le projet préexistant.</li>
<li><em>« L’équipe n’est pas prête pour ça »</em>… et c’est malheureusement parfois vrai.</li>
<li><em>« On a toujours fait comme ça et ça marche très bien »</em>, et son petit frère vicieux : <em>« Mais regarde, ce qu’on fait est déjà beaucoup mieux qu’avant »</em>.</li>
<li>Le cas très toxique de la personne qui bloque systématiquement toute modification qui fait qu’elle ne devient plus indispensable dans le processus (comme toutes les automatisations de tâches qu’elle faisait manuellement avant).</li>
</ul>
</li>
<li><strong>Les facteurs externes pas vraiment maîtrisés</strong> (ou que l’on imagine ne pas maitriser).
<ul>
<li><em>« Mais ça ne tournera jamais sur les machines de l’équipe en outsourcing »</em>. Parce qu’une partie du projet est développée dans un pays pas cher, sur des brouettes qui parviennent à peine à lancer un IDE avec un seul écran en 1366x768, accédées via le bureau à distance de Windows pour le télétravail.</li>
<li><em>« Les équipes d’installation chez le client ne sauront pas faire »</em>, pour les changements qui auraient des impacts sur le livrable final.</li>
</ul>
</li>
</ol>
<p>Et oui, tous les exemples sont réels…</p>
<p>Je rajoute que plus on monte dans la hiérarchie, plus c’est fréquent que les personnes aient du mal à comprendre autre chose que la rentabilité immédiate en argent. Or les problématiques de dégâts d’image (interne et externe à l’entreprise) et de démotivation des équipes (avec le turn-over et la perte de compétences, etc qui va avec) ont aussi un cout financier qui peut être énorme.</p>
<p>Je pense que ça peut être intéressant d’appuyer ces aspects, et de sortir des études qui montrent ces couts financiers.</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362362021-07-22T21:24:41+02:00Gabbro/@Gabbrohttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236236<p>Dans mon boulot actuel, c’est le temps, l’argument principal. Pour être précis, le temps « là tout de suite » : il y a des trucs urgents à faire de suite, donc la mise au propre peut attendre. Bien sûr, l’urgent sera remplacé par d’autres trucs urgent, et il faut donc des mois pour améliorer un peu les pratiques. À modérer : les modifs faites ont apportés de tels avantages (automatisations, reproductibilité) que dès que du temps se libère, les changements sont <strong>effectivement</strong> faits (et appréciés).</p>
<p>L’autre truc qui revient, c’est l’estimation des conséquences. Concrètement, on distribue des logiciels, sans signature, sans hash, sur un site en http. Nous n’avons aucune certitude que le logiciel envoyé et celui reçu par le client soit le même. Sauf qu’améliorer ça risque d’apporter des contraintes au client (à minima, aller chercher notre clé ou des trucs comme ça), donc c’est non. Les avantages les surpassent largement, mais risque client + prend du temps pour être bien fait = reporté <em>ad vitam eternam</em>.</p>
<p>Dans mon précédant travail, en labo…</p>
<ul>
<li>La question du responsable. Le responsable, mainteneur à longs termes du logiciel n’est pas forcément celui qui code. Typiquement, maintenance par le chercheur, code par les doctorants. Donc on impose au codeur le sous-ensemble connu du mainteneur. Qui s’est arrêté au Fortran 77, parce qu’il manque de temps pour se former. C’est un <strong>vrai</strong> exemple.</li>
<li>Le contournement est plus rapide que la résolution des problèmes à cause d’un historique catastrophique. Le logiciel maison ne compile que sur une machine, on n’a aucune idée de la raison, car les connaissances ont été perdues en cours de route, donc on déplace le codeur sur la machine plutôt que de chercher à pouvoir compiler partout.</li>
</ul>
<p>L’idée sous-jacente derrière ces deux exemples est que la dette technique ne concerne pas que les logiciels, mais aussi ses mainteneurs. « C’est trop compliqué » est la réponse type quand on demande des trucs propres. Et les faire soi-même n’est pas acceptable, parce que pas de transfert de connaissances possible.</p>
<p>Ça rejoint un point que je retrouve aussi dans mon travail actuel, même s’il n’est pas verbalisé explicitement : « on a toujours fait comme ça. » Pourquoi utilisé Git, un truc compliqué, quand on peut faire du <code>cp.old</code> ? On a toujours fait comme ça, et ça marche.</p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362312021-07-22T15:57:19+02:00viki53/@viki53https://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236231<p>Alors c’est pas des excuses, mais <a href="https://www.opquast.com/couts-de-non-qualite-pourquoi-lassurance-qualite-web-est-prioritaire/">cet article d’Opquast sur les coûts de non-qualité</a> liste pas mal d’arguments pour justifier la mise en place de process qualité.</p>
<p>Pas toujours facile de les évaluer, mais ça peut aider à trouver des arguments pour motiver les réfractaires <img src="/static/smileys/svg/smile.svg" alt=":)" class="smiley"> </p>De l'adoption de bonnes pratiques de développement en entreprise, message #2362302021-07-22T15:23:54+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15547/de-ladoption-de-bonnes-pratiques-de-developpement-en-entreprise/?page=1#p236230<p>Salut !</p>
<p>Aujourd’hui, on discutait sur le Discord de ZdS d’un sujet malheureusement trop fréquent, <strong>les préjugés à cause desquels les managers refusent que leur équipe adopte de bonnes pratiques de développement</strong>, et avec <a href="/@Spacefox" rel="nofollow" class="ping ping-link">@<span class="ping-username">Spacefox</span></a>, on s’est dit qu’il serait peut-être temps que l’on rédige un article rigoureusement sourcé pour démonter ces préjugés une bonne fois pour toutes, en espérant que cela puisse aider à faire bouger les choses dans le bon sens.</p>
<p>Afin de préparer cet article, j’aimerais que nous prenions le temps pour discuter de vos expériences, et notamment que nous prenions le temps de cibler ce sujet le plus précisément possible.</p>
<ul>
<li>Avez-vous déjà été confronté à un manager qui refusait de laisser votre équipe adopter de bonnes pratiques de développemment (tests automatisés, TDD, intégration continue, code reviews, pair programming…) ?</li>
<li>Pouvez-vous nous raconter le plus précisément possible les arguments et/ou préjugés qu’ils vous ont opposés pour cela ?</li>
</ul>
<p>On pourra bien sûr discuter des raisons pour lesquels ce sont des préjugés et de la bonne façon pour leur montrer qu’ils se trompent, de préférence en utilisant des sources solides et variées, mais l’objectif de ce thread est déjà de déterminer <em>ce à quoi</em> un tel article doit répondre.</p>
<p>Par exemple, l’un des préjugés qui revient assez souvent est que l’on "n’a pas le temps" de mettre en place des tests automatisés ou une CI, ce qui revient à ignorer que c’est tout le contraire, puisque la littérature (Kent Beck et Robert C. Martin, typiquement) a déjà permis de montrer que ce temps investi dans la mise en place de tests ou d’une CI est négligeable devant celui perdu à réparer des régressions qui ne sont détectées qu’en production en raison de leur absence…</p>
<p>Bref, c’est à vous !</p>Parler comme un avion, message #2334942021-04-22T00:11:51+02:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/13604/parler-comme-un-avion/?page=1#p233494<p>Au final, je n’aurais jamais réussi ! ahah <img src="/static/smileys/svg/1f605.svg" alt="😅" class="smiley"> </p>
<blockquote>
<p>En fait, à mon sens, la question est exactement la même que lorsque tu souhaites apprendre une langue. L’immersion marche pour beaucoup, comme l’indique qwerty, mais tu peux voir s’il n’y a pas des analyses de discours pour le groupe social que tu cherches à imiter, ça peut peut-être donner des clés.</p>
</blockquote>
<p>Comment s’immerger quand on n’a pas le/les modèles à disposition socialement ? <img src="/static/smileys/svg/1f914.svg" alt="🤔" class="smiley"> Comment apprendre ? Je serais toujours curieux de connaître la réponse, plus que jamais. Même si je dois fouiller dans zlib ou d’autres documents payants.</p>Candidature spontanée à l'équipe de communication , message #2260212020-09-16T18:00:50+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226021<p>De mon point de vue, il faut surtout qu’on <em>ait une communication</em>. Aujourd’hui c’est le néant.</p>Candidature spontanée à l'équipe de communication , message #2260192020-09-16T17:21:15+02:00Arius/@Ariushttps://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226019<blockquote>
<p>Il faut pour moi qu’on garde l’image qu’on a actuellement, bien qu’il faille se faire connaître plus. Mais si c’est de cette manière, je préfère que l’on ne fasse rien</p>
</blockquote>
<p>Je suis d’accord. </p>
<p>Mais cela mérite une discussion propre à la "stratégie de communication", soit au sein de l’équipe comm’, soit au niveau de la communauté en général. Ce que nous voulons, ce que nous voulons pas, ce que nous pouvons faire (ou pas), etc. L’essentiel est qu’il y ait une "ligne de conduite" claire. </p>Candidature spontanée à l'équipe de communication , message #2260182020-09-16T16:35:30+02:00Melcore/@Melcorehttps://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226018<figure><blockquote>
<p>Il faut pour moi qu’on garde l’image qu’on a actuellement, bien qu’il faille se faire connaître plus. Mais si c’est de cette manière, je préfère que l’on ne fasse rien</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226017">Helmasaur</a></figcaption></figure>
<p>Bon après, il n’a jamais était question de faire de la communication à la Netflix, ZDS ne fait pas du divertissement. </p>
<figure><blockquote>
<p>Poster les infos c’est bien mais <strong>participer tel un être humain</strong> c’est tellement plus efficace ! D’ailleurs, les grandes marques l’ont bien compris (cf. la façon de communiquer de Netflix ou d’Interflora sur Twitter, ou plus proche de nous, du CNES et d’ArianeGroup… c’est tout dans la communication directe, réponse aux tweets, participations, …)</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p225951">Amaury</a></figcaption></figure>
<p>Participer tel un etre humain ça veut aussi dire répondre aux questions, participer à la vie de twitter (du coté scientifique tout du moins), aller à la recherche de potentiels auteurs qui n’ont pas de plateformes pour se démarquer.</p>
<figure><blockquote>
<p>Ce plagiat du post de <a href="/membres/voir/Melcore/" rel="nofollow" class="ping ping-link">@<span class="ping-username">Melcore</span></a></p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p225947">AmarOk</a></figcaption></figure>
<p>J’avais dit dans ma candidature que je suis un influenceur <img src="/static/smileys/svg/hihi.svg" alt="^^" class="smiley"></p>Candidature spontanée à l'équipe de communication , message #2260172020-09-16T16:24:09+02:00Helmasaur/@Helmasaurhttps://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226017<p>Le compte de Netflix fait surtout faux, hypocrite et faux-cul. C’est peut être ça, humanisé… Plus sérieusement, je trouve ça agressif et sournois. Je serais vraiment déçu de voir des tweets à la Netflix.</p>
<p>Il faut pour moi qu’on garde l’image qu’on a actuellement, bien qu’il faille se faire connaître plus. Mais si c’est de cette manière, je préfère que l’on ne fasse rien</p>Candidature spontanée à l'équipe de communication , message #2260102020-09-16T12:07:57+02:00Amaury/@Amauryhttps://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226010<p>Merci pour vos réponses (et pour votre confiance).</p>
<p>Je fais maintenant parti de l’équipe de communication.</p>
<hr>
<p><em>(Cette partie de ce message est postée sans casquette.)</em></p>
<figure><blockquote>
<blockquote>
<p>Pourquoi ? Humaniser un compte "pro" se fait beaucoup parmi les CM. Si c’est ça qui te dérange dans la communication de Netflix, tu n’as clairement pas le meme avis que la majorité. Et de toutes évidences, c’est efficace.</p>
</blockquote>
<p>Sans aller dans les histoire de ce que "la majorité pense" ; effectivement la communication de Netflix n’est pas si … classe que ça. ZdS peut viser mieux, bien mieux.</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p225980">Holosmos</a></figcaption></figure>
<p>Je plussoie. Si je mentionnais le cas de Netflix c’était surtout sur la façon d’humaniser le compte (comme LibreOffice effectivement), mais je ne trouve pas que leur façon de faire précisément soit la meilleure, loin de là. Ça marche, mais est-ce que c’est une image souhaitable ? Pas sûr.</p>
<p>On peut toujours s’inspirer de ce genre de méthodes de communication mais en évitant de tomber dans les travers associés <img src="/static/smileys/svg/smile.svg" alt=":)" class="smiley"> .</p>Candidature spontanée à l'équipe de communication , message #2260062020-09-16T11:18:44+02:00Moté/@Mot%C3%A9https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226006<p>Moi j’exprime un avis positif en tant que membre.</p>Candidature spontanée à l'équipe de communication , message #2260052020-09-16T11:11:00+02:00viki53/@viki53https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p226005<p>J’ai le droit d’exprimer un avis positif en tant qu’ancien de l’équipe Comm ? <img src="/static/smileys/svg/heureux.svg" alt=":D" class="smiley"> </p>Candidature spontanée à l'équipe de communication , message #2259822020-09-15T20:58:04+02:00Melcore/@Melcorehttps://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p225982<figure><blockquote>
<p>De ce qui ressort de la discussion apr MP, <a href="/membres/voir/ache/" rel="nofollow" class="ping ping-link">@<span class="ping-username">ache</span></a> <a href="/membres/voir/elyppire/" rel="nofollow" class="ping ping-link">@<span class="ping-username">elyppire</span></a> ou moi n’ont rien contre la candidature d'<a href="/membres/voir/Amaury/" rel="nofollow" class="ping ping-link">@<span class="ping-username">Amaury</span></a>, on peut s’organiser par MP</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/14528/candidature-spontanee-a-lequipe-de-communication/?page=1#p225981">AmarOk</a></figcaption></figure>
<p>Et du coup, moi non plus <img src="/static/smileys/svg/hihi.svg" alt="^^" class="smiley"></p>