English version available

Comment écrire un article de blog? A plusieurs reprises, j’ai reçu des messages de lecteurs me demandant des conseils autour de ce sujet.

• Comment trouver des idées?
• Comment faire le tri dans ses pensées avant de se plonger dans l’écriture?
• Est-ce que je suis un processus particulier?
• Ai-je des conseils à partager avec quelqu’un qui aimerait commencer à bloguer?

Je me souviens encore du jour où j’ai commencé ce blog, il y a près de 13 ans (au moment où j’écris ceci, je me rends compte à quel point cela sonne préhistorique). A l’époque, mon objectif initial était de publier une fois par mois sur des sujets variés liés à l’informatique, que ce soit sur des thématiques liées à mon travail, ou à des projets personnels. Si cela fonctionnait plutôt bien au début, ces derniers temps, je dois l’avouer, cela ne fonctionne pas si bien que ça. J’ai presque honte quand je regarde la date du dernier (précédent) article, il y a plus d’un an, c’est de loin la plus grosse période d’inactivité sur mon blog!

Aujourd’hui, j’ai décidé d’écrire sur ce sujet en particulier, non seulement parce que l’on m’a interrogé à plusieurs reprises à ce propos, mais aussi parce que cet article représente une étape importante pour mon blog. C’est en effet le 100ème article, et c’est l’occasion parfaite pour écrire sur un tel sujet même si c’est quelque chose d’inhabituel et non technique.

Pour être honnête, à moins que cela fasse partie d’un travail à plein temps, il faut un certain dévouement pour écrire des articles, car cela prend pas mal de temps, et je ne pense pas qu’il y ait de recette magique. L’état d’esprit de chacun fonctionne différemment, et ce qui peut fonctionner pour moi pourrait avoir l’effet inverse sur vous. Néanmoins, dans cet article, je vais essayer de décrire ma recette qui fonctionne. Du moins je l’espère, je l’ai appliquée pour écrire cet article donc vous pouvez juger de la méthode par vous-même.

L’idée

Tout commence par une idée (ça ressemble à une bande-annonce de film je sais mais c’est vrai). Une idée est une phrase courte, un ensemble de mots-clés tout au plus, qui représente un sujet particulier, ni trop spécifique, ni trop vague. Il n’y a pas de moment précis pour avoir une idée, cela peut être en travaillant, en pianotant sur son ordinateur, en marchant, en prenant une douche. Une idée pointe le bout de son nez généralement bien avant que vous ne commenciez à écrire du contenu à son sujet, mais ce n’est pas toujours vrai, et vous pourriez trouver une idée qui vous passionnera à tel point que vous allez commencer à écrire un article dans l’heure qui suit.

Personnellement, je conserve toutes mes idées sous la forme d’une liste à puces non ordonnée dans un fichier texte sur mon ordinateur. Pour vous donner une idée (oui celle-ci était facile désolé), j’ai actuellement 9 idées dans cette liste.

Tout au long de l’année, j’ai ce puits d’idées dans lequel je peux puiser pour écrire des articles. Comme je l’ai mentionné précédemment, il n’y a pas de règles lorsque vous sélectionnez une idée ; parfois j’écris un article sur une idée que je viens juste d’ajouter (cet article en fait partie), d’autres fois j’écris un article sur une idée que j’ai ajoutée il y a 3 ans. La plupart des idées que j’ai maintenant ne feront probablement jamais l’objet d’un article, il est donc normal d’en abandonner un grand nombre au fil du temps, et cela pour diverses raisons, par exemple l’idée:

• n’est pas suffisamment bonne pour faire un article intéressant ;
• n’est pas alignée avec la ligne éditoriale de mon blog, c’est-à-dire qu’elle cible un tout autre public ;
• est portée sur un sujet niche trop spécialisé ;
• ou, au contraire, concerne un sujet archi connu et déjà couvert par de nombreux blogueurs.

Contenu brut

Une fois que j’ai sélectionné l’idée, je trouve 1 ou 2 heures dans mon agenda et je commence à écrire. J’ai besoin d’un temps de concentration maximum, et si je peux j’évite de faire des pauses pour limiter toutes coupures et autres distractions. Ici, je parle d’écrire du contenu pur, une version vraiment brute de décoffrage, tout ce qu’il peut me passer par la tête quand je pense à cette idée, ça peut être sous forme de phrases complètes, de listes à puces, de quelques liens ou une description textuelle des futurs images ou schémas que je souhaiterais inclure, etc.

Cela dépend de l’idée, mais s’il s’agit d’une idée très technique, je peux aussi faire une préparation préalable et utiliser des notes prises précédemment, par ex. il peut s’agir de quelques lignes de code ou d’autres exemples de programmation. Je peux également faire des recherches supplémentaires sur Internet pour savoir s’il y a autre chose auquel je n’ai pas pensé. Ce n’est pas une mauvaise chose de s’inspirer d’autres sources, bien sûr tant que vous ne paraphrasez pas ou ne faites pas de plagiat!

A ce stade, je ne fais pas attention ni à l’orthographe, ni aux fautes de frappe et autres fautes de grammaire, j’écris littéralement ce qui me passe par la tête et que je ne voudrais pas oublier. J’utilise un simple éditeur de texte plutôt que d’utiliser l’éditeur de blog en ligne afin d’éviter toute distraction.

Cela ne vous concerne peut-être pas, mais comme mon blog est bilingue, avec un contenu disponible en français et en anglais, je dois aussi décider dans quelle langue je vais écrire en premier. Selon moi, je ne pense pas qu’il soit très efficace d’écrire dans les deux langues en parallèle, et je préfère me concentrer sur une seule à la fois en laissant la traduction à la fin. La plupart du temps et même si le français est ma langue maternelle, j’écris d’abord en anglais. La raison principale est que je risquerais d’écrire des phrases trop complexes en français qui seront difficilement traduisibles en anglais, une autre raison est le fait que je travaille dans le secteur des technologies dans un environnement anglais, donc cette langue est tout simplement plus naturelle (je n’aurais jamais pensé écrire ça un jour!).

Réviser, Améliorer, Peaufiner, Répéter

Maintenant que j’ai couché sur papier (numérique) toutes les informations associées à mon idée, on pourrait penser que je suis à peu près à 60% du processus d’écriture. Malheureusement, c’est loin d’être le cas, et de façon réaliste, je dirais que je n’ai fait qu’environ 30%.

C’est à ce moment qu’entre en piste un processus itératif de révision et d’amélioration, plutôt long et fastidieux. C’est l’étape la plus longue de la rédaction d’un article, mais aussi la plus importante, c’est là que la structure de l’article va prendre forme. Je réorganise mes pensées de manière logique afin que le contenu soit facile à lire et à suivre pour mes lecteurs. Les retours à la ligne, les paragraphes, les sections, les titres et les sous-titres apparaîtront naturellement au fil des révisions. Il est tout à fait acceptable de supprimer une section si vous réalisez qu’elle ne s’intègre pas avec le reste, ou de développer une section si certains détails ont été omis, ou même de réécrire des pans entiers de texte.

Il est important d’adapter le ton de voix et de le garder cohérent à travers tous vos articles. Si c’est votre propre blog, c’est quelque chose auquel vous ne penserez sûrement pas, mais imaginez que vous écrivez un article dans un blog d’une revue scientifique dont le contenu est écrit par plusieurs auteurs, écrire une blague est probablement la dernière chose que vous voudriez faire…

A noter que j’arrête d’utiliser le simple éditeur de texte au profit de l’éditeur de blog en ligne, ainsi je peux donc utiliser le mode aperçu et voir le rendu final de l’article. C’est important, car cette étape ne se concentre plus uniquement sur le texte, mais je pense aussi aux images que j’aimerais intégrer, aux liens que j’aimerais inclure et à la mise en forme que j’aimerais appliquer.

Le Visuel

Lorsque vous ajoutez des images, n’en faites pas trop. Non seulement l’ajout d’images aura un impact non négligeable sur la bande passante, mais pourra également causer une certaine distraction pour vos lecteurs. Dans la plupart des cas, une image en haut de l’article suffira.

Pour rechercher l’image parfaite et si vous n’êtes pas satisfait de vos propres photos, vous pourriez être tenté d’utiliser Google Images, mais il existe bien d’autres ressources disponibles, qui vous éviteront notamment toute forme de violation du droit d’auteur.

• Unsplash
• Pexels
• The Noun Project

Peut-être devez-vous créer un diagramme ou un schéma? Personnellement, j’utilise PowerPoint, ce n’est peut-être pas le meilleur outil, mais il a un rendu que j’apprécie et je suis très familier avec la suite Office. Au cas où j’aurais besoin de générer un schéma plus technique, j’utilise également PlantUML. Cela dépendra vraiment de ce sur quoi vous écrivez et de votre domaine d’expertise, bref, choisissez l’outil que vous préférez!

Liens

Lorsque vous ajoutez des liens, n’en faites pas trop. Le lien est l’outil fondamental pour naviguer sur Internet, il aide à référencer les sites Web incluant le vôtre, mais l’ajout de nombreux liens pourrait être distrayant et votre lecteur pourrait finir par penser que vous faites de la publicité plutôt que de fournir du contenu informatif.

Lorsque vous ajoutez des liens, assurez-vous qu’ils ont tous une utilité. Aident-ils le lecteur à obtenir plus de contexte? Permettent-ils au lecteur d’accéder à un outil que vous avez mentionné? Il est très important d’étiqueter correctement votre lien et de ne pas utiliser le typique « cliquez ici » qui ne contient aucun contexte.

A l’inverse, ce n’est pas la fin du monde si votre article ne contient aucun lien ou seulement quelques-uns. Cependant, je suggérerais d’avoir au moins une section en bas de l’article avec une liste de liens utiles. Cela peut être à titre de référence (c’est aussi une façon de remercier les auteurs dont vous vous êtes peut-être inspiré), mais cela peut également être utile si le lecteur souhaite aller plus loin sur le sujet.

Mise en page

Lorsque vous ajoutez la mise en forme, n’en faites pas trop. La cohérence et la simplicité sont des concepts clés.

Vous pouvez utiliser plusieurs niveaux pour différencier les titres principaux des sous-titres. Personnellement, je me limite à 2 niveaux maximum. Si vous avez besoin de plus, votre article est peut-être trop complexe et il faudrait peut-être envisager de le décomposer en une série d’articles.

En général, espacez votre texte et évitez les phrases longues et complexes qui ont tendance à générer des pavés. Utilisez des listes à puces quand cela a du sens, pas partout.

Certaines mises en forme de texte mineures comme le gras et l’italique peuvent être utiles, mais à utiliser avec parcimonie.

• Le gras peut souligner une idée et attirer l’attention du lecteur.
• L’italique peut être utilisé pour introduire un terme technique ou pour citer un texte.

Dernière Revue

A ce stade, il est primordial d’utiliser le mode aperçu de votre éditeur de blog, ainsi vous pourrez vérifier qu’il n’y a pas de liens cassés, que les images sont rendues correctement au bon endroit dans les bonnes dimensions, que la mise en forme et l’espacement fonctionnent comme prévu, etc.

Je dois admettre que j’utilise Word pour la vérification de mon orthographe et grammaire, je copie le contenu complet dans un document Word, puis je répercute les éventuelles corrections suggérées dans l’article. Un outil plus sophistiqué comme Grammarly ou Antidote peut également être une aide précieuse, ces outils s’intègrent directement dans votre navigateur donc vous n’aurez même pas besoin de transférer le contenu.

Si vous connaissez quelqu’un prêt à vous aider et relire votre article, cela peut être un collègue, un ami ou un membre de votre famille, demandez-lui! Il est toujours bon d’avoir des yeux supplémentaires sur votre travail. Personnellement, je saute cette étape et fais ma propre revue. Mais faire comme moi peut être légèrement risqué, surtout si vous publiez au nom de votre entreprise par exemple. Je suis à peu près sûr d’avoir de nombreux articles publiés avec des fautes, c’est particulièrement vrai dans la version anglaise de mes anciens articles (j’espère que mon anglais s’est amélioré depuis). Encore une fois, ce n’est pas la fin du monde, surtout si cela se produit sur un blog personnel, vous avez déjà pris du temps pour écrire et partager vos connaissances, et votre lecteur ne vous jugera pas pour cela.

Comme le titre l’indique, il s’agit d’une dernière revue, alors ne révisez pas encore et encore. Je sais qu’il peut être tentant d’améliorer à nouveau votre texte. Je pense que ça peut être mieux comme ça. Je pense que je suis allé trop dans les détails dans cette partie et pas assez dans celle-là. La formulation n’est pas super ici. Et si j’utilisais cette phrase à la place? Soyons honnêtes, il y a peu de chance que vous soyez pleinement satisfait.

Puisque vous avez déjà passé plusieurs heures sur votre article, il est temps de lâcher prise et de cliquer sur le bouton de publication! Ah, enfin, n’oubliez pas de trouver un bon titre, il doit être court, accrocheur et véhiculer l’idée principale de votre article.

Traduction facultative

Dans mon cas, je n’ai pas encore fini, je dois aussi traduire l’article en français avant de publier.

Bien que le français soit ma langue maternelle, je prends des raccourcis pour accélérer le processus de traduction et j’utilise Google Translate. Je peux donc partir d’une base et d’un texte déjà traduit que je peux ensuite relire, reformuler quelques phrases ici et là. La traduction automatique n’est pas parfaite, mais je dois dire qu’elle est plutôt bonne, je dirais qu’environ 70% du contenu est généralement laissé intact ou avec des modifications mineures.

A moins que je doive recréer quelques schémas en français, la traduction est probablement la partie la plus rapide à faire, puisque je garde les mêmes images, le texte et la mise en forme, et le français est évidemment plus facile pour moi…

Bon blog!

 English version available

Voici un article sans prétention qui rejoint des articles de plus en plus nombreux sur la toile venant à l’encontre des idées reçues sur le métier de développeur. Vous allez voir que ce métier est loin de se résumer à la « simple » écriture de code.

Métier multisectoriel

Tout d’abord, l’informatique étant un métier transversal, le développeur ne connait pas de limites au niveau des secteurs d’activité qui s’offrent à lui. Pour ma part, j’ai été amené à travailler sur des projets dans des secteurs aussi variés que sont l’automobile, l’énergie, la téléphonie ou bien encore la santé. Bien sûr, à chaque fois, il faut s’adapter, acquérir une bonne compréhension du fonctionnel et de la logique business, des paramètres indispensables dans la réussite d’un projet. Pouvoir travailler dans des secteurs différents est une grande liberté, cela vous amène à rencontrer des personnes de milieux différents, c’est très enrichissant. Aussi, vous pouvez vous faire une idée sur chacun et privilégier les secteurs qui vous intéressent le plus. Ce n’est pas donné à toutes les professions.

Vision projet dans sa globalité

Un développeur participe principalement durant la phase de développement d’un projet informatique, mais il doit aussi comprendre l’ensemble des composantes d’un projet. L’implémentation ne représente qu’une toute petite partie de la vie d’un projet informatique. Il n’y a pas besoin d’avoir une maitrise complète d’un projet de bout en bout, simplement avoir une notion des activités qui gravitent autour. En effet, les étapes sont nombreuses entre la naissance d’une idée et la vente de la solution, et cela ne s’arrête pas là.

Autonomie & communication

Il est vrai qu’un développeur est souvent devant son écran et participe peu à des réunions, l’autonomie est une qualité souvent exigée. Pourtant, l’aspect communicatif et collaboratif n’est pas en reste, il est indispensable d’avoir un bon relationnel: pouvoir travailler en équipe, comprendre et discuter avec le client ou le chef de projet. Un projet informatique se fait rarement tout seul, une bonne communication est donc primordiale. On ne compte plus les outils collaboratifs disponibles dans la panoplie d’un développeur.

Architecture logicielle

Bien évidemment, le développeur est un poste technique et il passe beaucoup de son temps à écrire du code. Ecrire des suites d’instruction avec des « if », des « else » est une vision dépassée. Le code est réfléchi et suit une architecture logicielle bien précise. La programmation est objet, fonctionnelle, les architectures sont modulaires, utilisent des patterns spécialisés et le modèle doit être bien pensé au plus tôt. L’architecture logicielle peut rapidement devenir complexe sur de gros projets. C’est pour cela qu’écrire un code maintenable est primordial, les composants doivent avoir été écrits pour pouvoir évoluer facilement.

Qualité logicielle

Le développeur a aussi une casquette de testeur. Certes, ce n’est pas l’utilisateur final, mais il écrit quand même des tests (on parle de tests techniques: unitaires et d’intégration). Il s’assure que la fonctionnalité livrée répond au besoin et que l’existant fonctionne toujours (non-régression). Il a aussi la connaissance et la maitrise de nombreuses métriques de qualité sur son code. Il est sensibilisé à la dette technique et s’arrange pour la diminuer en reprenant le code en cas de besoin (on parle de refactoring).

Maitrise des outils

Le développeur connait de nombreux outils qui l’aident dans la réalisation de ses tâches quotidiennes, que ce soit des outils applicatifs (IDE, gestionnaires de versionning, de bugtracking, plateforme d’intégration continue, analyseurs de code, etc.) ou des outils purement techniques (frameworks, librairies utilitaires, bases de données, etc.). On utilise autant que possible des outils existants, il est très rare de partir de zéro pour réaliser un projet. Le choix des outils est lui aussi quelque chose qui a été mûrement réfléchi.

Veille technique

Un développeur doit apprendre, apprendre et toujours apprendre pour éviter d’être dépassé techniquement. Il est vital de s’informer, de s’autoformer sur les nouvelles technologies et de tester de nouveaux outils. Cela ne doit pas aller à l’extrême et ce n’est pas parce que l’on ne passe pas son temps libre à aller au Devoxx, écouter les Castcodeurs, suivre des cours sur Coursera que l’on est un développeur non passionné ou un mauvais développeur. A noter aussi que certains développeurs se spécialisent sur d’anciens langages de programmation où le besoin de se tenir à jour est limité, car les technologies n’évoluent plus ou très peu. C’est un choix de carrière.

Proche de la machine

Le développement est une activité technique, mais elle se fait en général avec des langages de programmation de haut niveau. Le développeur doit tout de même avoir des notions de ce qui se passe sous le capot, se poser des questions sur les frameworks qu’il utilise, les concepts sous-jacents, comprendre les mécanismes de compilation, la gestion de la mémoire, de la performance, comprendre le stockage de l’information, la gestion des nombres à virgules flottantes, etc. Même s’il ne maitrise pas tous ces concepts, avoir quelques notions lui sera très utile.

Le métier de développeur est donc très complet et revêt de multiples facettes. Au-delà de cela, je pense que les mentalités en France et dans d’autres pays européens sont en train d’évoluer progressivement vers la bonne direction. Le métier de développeur devient un métier de plus en plus valorisé. Pour finir, je peux difficilement ne pas faire une comparaison avec ce qui se passe outre-Atlantique. Aux États-Unis, les développeurs sont très bien considérés et certains d’entre eux sont parmi les personnes les plus riches de la planète… A méditer!

Pour approfondir le sujet, je vous recommande la lecture de ces quelques articles, et en bonus une petite vidéo pour finir sur une touche de légèreté.

• Tariq Krim: « Les développeurs anonymes d’aujourd’hui peuvent créer les géants de demain »
• Comment valoriser les développeurs ?
• Ne dites pas à ma mère que je suis développeur
• Putain Bob tu m’énerves !
• Travailler autrement
• Rencontre avec Ludwine, développeuse
• Développeur après 31 ans ? Ridé et chauve tu seras