DEV Community: Dutcom

Dumb social network - reprendre le contrôle

Dutcom — Mon, 31 Aug 2026 18:55:01 +0000

Une des plus grosses avancées de notre génération est la capacité à s'interconnecter et à partager des sujets.

Merci les réseaux sociaux ❤️

À l'instar du smartphone, le problème qu'engendrent les réseaux sociaux est systémique, l'addiction est là.

Les designers ne sont pas philanthropes, ils sont là pour vendre du temps d'attention. Votre attention.
Il faut également comprendre que l'algorithme met en avant le contenu qu'il considère comme pertinent, ce qui est très subjectif et peut poser des problèmes d'équité.
Certaines publications n'apparaîtront jamais.

Alors comment avoir le meilleur des mondes ?

L'objectif, continuer à s'informer, s'instruire, partager.. sans finir par digger pendant des heures sur des vidéos de chat.

Comme pour le dumbphone, il faut rendre les réseaux sociaux plus "débiles" 🫪

Voici pour moi les choses que les géants de la tech utilisent pour nous tenir attentifs :

Le scroll infini
Le contenu publié en permanence
Le contenu viral court (short/tiktok/reels)

La vision extrémiste serait de désinstaller tous les réseaux sociaux (ce que j'ai tenté de faire), mais faut-il vraiment se priver d'une des évolutions majeures de notre époque ? Ou plutôt tenter de les contrôler ?

C'est tout l'objet de ce POC.

Mon cahier des charges :

Avoir seulement accès à mes créateurs de contenus.
Une seule interface pour tous les réseaux sociaux.
Sans scroll infini
Avec un rafraîchissement une seule fois par jour
Un tri par réseaux sociaux
Un tri automatique par date
10 contenus maximum par créateur
Responsive

La solution va s'appuyer sur quelque chose de très connu, les flux RSS 👵🏻.

Un flux RSS est un fichier textuel dynamique au format XML qui structure les métadonnées d'un site (titres, liens, dates, résumés) pour qu'elles soient lisibles par un script ou un agrégateur.

Bon ben voilà, solution trouvée, un extrait manuel ou automatique de mes créateurs préférés, on l'importe dans un saas bien brandé comme feedly et l'histoire est réglée 🚀

Hééééé, noooon. 🥲

Ça ne respecte pas scrupuleusement le cahier des charges que je me suis fixé.

On se rend dépendant d'une nouvelle entreprise, la limitation dans l'application avec le plan gratuit est présente et tous les réseaux sociaux ne sont pas pris en compte.
Je chipote pas mal, mais j'ai vraiment trouvé que l'user expérience n'est pas ce que je recherche.

Peut-être que vous trouverez ça suffisant, et auquel cas l'effort pour répondre le contrôle sera minime !

Ok, mon esprit torturé aime bien ce défi, on se retrousse les manches et on se met à coder.

Par défaut, certains réseaux sociaux ou sites web embarquent leur propre flux RSS.

Dans un souci d'uniformisation (et parce que j'ai vraiment beaucoup envie de tester cet outil) je vais utiliser RSShub.

Il permet de pouvoir créer un flux RSS avec le contenu que vous voulez.

Une fois le container déployé et quelques clés API renseignées, me voici en capacité de récupérer tout ce que je souhaite.

Deux options, soit j'utilise une solution self hosted qui me permet d'avoir un front prêt à l'emploi sur lequel je le connecte directement à RSShub (EZ).
Soiiiit je crée mon propre front/back.

Pourquoi faire simple quand on peut faire compliqué...

Pour un PoC (proof of concept) on ne va pas non plus trop se compliquer la vie, rajouter à ça le fait que je sois une pince et j'ai mon architecture toute trouvée.

Pas de base de données et un front statique tu seras.

Pour l'extraction un petit script python avec en input mes créateurs de contenus.

Pour la sauvegarde des données ça sera dans un fichier JSON.

Pour l'UI j'utilise une solution IA du nom de stitch, ça va me créer un rendu comme avec figma que je peux facilement exporter en HTML.
Je retravaille un petit peu le HTML avec mes petites compétences, pour finir par "vibes coder" le reste. Notamment la partie JS et l'intégration du fichier JSON.

On a maintenant quelque chose qui fonctionne en local.

Pour savoir si cela correspond bien à mon besoin, si cela me permet réellement de passer moins de temps sur les réseaux sociaux et si le contenu récupéré est de qualité, il faut que je puisse l'utiliser comme une application classique.
Donc le mettre "en ligne".

Étant donné que j'ai un homelab fonctionnel, on va faire simple, un docker compose d'un serveur NGINX et un cron pour le lancement du script une fois par jour.

Pour l'accès j'utilise tailscale. Tous mes devices ont maintenant accès à cette petite solution.

Alors, le bilan ?!

Hé bien oui, effectivement cela correspond à mon besoin. Rassurez-vous, je ne ferai pas d'ombre aux GAFAM mais l'intérêt est bien là.
La qualité plutôt que la quantité.

Tout n'est qu'une question d'équilibre, bien sûr que l'algorithme est génial pour trouver de nouveaux contenus. Bien sûr que je continuerai à l'utiliser partiellement.
Mais je ne pense pas que ce soit nécessaire d'en découvrir en permanence.
Peut-être que c'est une nouvelle façon de consommer du contenu ?

Essai - Le prix de l'échec

Dutcom — Mon, 31 Aug 2026 17:27:27 +0000

De part mon expérience et ceux de mes proches je sais que l'échec fait partie du chemin.

Ceux qui vont loin ont appris à vivre avec.

Mais alors qu'est-ce que l'échec ? Qu'est-ce que cet essai va apporter ? 🤷🏻‍♀️

Pour les plus optimistes d'entre nous, l'échec n'existe pas vraiment, car même si on n'arrive pas au résultat attendu, le chemin nous aura appris beaucoup, bla bla bla...

Laissons de côté la philosophie et attaquons le sujet sous un angle concret. L'échec dans le business. 🚀

J'ai pour ma part essayé de créer une structure qui n'a pas fonctionné comme je le souhaitais, mais j'ai su par les erreurs des autres quand arrêter et rebondir.

J'ai vu mon père monter une structure qui a fonctionné sur une période très courte et qui ne l'a pas été sur une période très longue.

J'ai vu mon frère réussir bien plus que ce que j'imaginais et pour autant tout perdre à plusieurs reprises.

L'échec et sa gestion est différente pour chaque individu.

Une formule de quantification du prix de l'échec pourrait ressembler à ça :

Prix de l'échec = impact financier + impact temporel + impact mental.

L'échec fait partie de notre réussite.

Sans elle rien n'existerait.

Les anciens modèles reposaient sur une phase d'étude extrêmement longue pour être sûr de ne pas échouer.

Aujourd'hui les choses ont changé.

Fail, Learn, Repeat

Si je devais nuancer mes propos, je devrais dire que chaque modèle ont leurs qualités et leurs défauts et que c'est à nous de choisir le bon en fonction de notre besoin.

Mais on s'attardera seulement sur la vision qui m'arrange dans cet essai.
Notre capacité à échouer et se relever le plus rapidement.

Dans cette optique nous devons donc minimiser son prix...

Impact financier :

Qu'il soit petit ou grand, les dépenses sont systématiques, impossible d'y échapper.
Elles peuvent se diviser en 4 grandes catégories :

Personnes/services : de l'embauche d'un salarié en CDI, le freelance qu'on peut payer à l'heure, à la société de transport.
Produits physiques : avec les outils, matière première ou foncier.
Les produits digitaux, celui-là peut être sous-estimé, on parle ici des offres SaaS, de votre infrastructure, site web, email etc.
Légaux : Les impôts, les taxes ou les obligations légales à réaliser pour la création et le maintien de la société.

Impact temporel :

Il peut être lié à l'impact financier.
Le temps c'est de l'argent.
Mais là j'aimerais surtout souligner le coût du temps à l'échelle humaine.
S'investir deux ans dans un projet correspond réellement à prendre deux ans de son espérance de vie.
Deux ans qui pourraient être consacrés à autre chose.

Les passions, les voyages, la famille.
Si nous faisons des généralités, la vie des occidentaux est plutôt normée.
École / travail / retraite.
Il est possible de se lancer dans l'entrepreneuriat à n'importe quel moment.
Mais il y a des moments plus propices que d'autres.

Deux ans de votre vie au moment où votre enfant vient de naître n'a pas le même coût que deux ans sorti d'étude sans aucune responsabilité.

Impact mental :

Pour celui-là, cela peut être un combo des deux.

Perdre énormément d'argent et ne pas voir ces enfants grandir n'est pas forcément très facile à accepter pour tout le monde.
Mais c'est aussi une question de société.
Échouer n'est pas bien vu.
L'école ne nous apprend pas à échouer.
Si on a des mauvaises notes, nous avons échoué, nous sommes donc un mauvais élève.
Ce schéma est suivi à l'âge adulte.
Il est parfois très compliqué de gérer cette pression.

Ma petite conclusion

Je n'ai pas listé ces différents aspects pour le plaisir.
Le but est de mieux comprendre comment réduire ce "prix de l'échec" qui nous empêche de réessayer jusqu'à réussir.

L'objectif est d'être conscient et de mettre les meilleurs moyens en place pour faire quelque chose de réfléchi.

L'échec n'est que l'étape d'avant la réussite.

Il n'est pas la finalité.

Tout cela peut être adapté à plusieurs choses en dehors du business.

J'espère que cette essai ne vous aura pas appris à réussir mais plutôt que rebondir après un échec est essentiel.

Mini DAT Cloud ☁️

Dutcom — Fri, 21 Nov 2025 11:02:27 +0000

Au non pas un DAT 🥹

Généralement, la réalisation de livraison écrite est souvent la bête noire de l'informaticien.
Et pourtant, je vais essayer de vous réconcilier avec la réalisation d'un document d'architecture technique MEME si ce n'est pas imposé par votre service informatique.

J'aimerais vous faire part de ma vision très orientée infrastructure cloud, elle ne collera pas à 100% avec votre spécialité on-prem ou même logiciel mais je suis sûr que tout n'est pas à jeter... Enfin, peut-être...

Premièrement, ce N'EST PAS UNE PUNITION. L'objectif est de vous poser les bonnes questions avant de vous lancer tête baissée dans la mise en PROD de votre infrastructure. Vous me remercierez quand vous verrez vos collègues faire un rollback à 1 semaine de la MEP mais pas vous.

Imaginez, vous récupérez un vieux sujet poussiéreux totalement WTF. Et là, vous trouvez le saint graal, le DAT.
Si celui-ci est bien réalisé, vous allez comprendre pourquoi une solution a été designée comme ça. Il y a beaucoup d'esprit malade dans ce monde (dont je fais très certainement partie) mais parfois ils ont leur raison et le DAT nous aide à y voir un peu plus clair.
Alors, vous aussi contribuez à l'équilibre mental de la prochaine personne qui récupérera votre travail 😉.

N'oubliez pas qui est la cible de ce document, votre direction, une autre équipe, des architectes de solution... etc.
Ce sont eux qui vont valider votre projet. L'objectif est de rassurer et montrer que vous maîtrisez votre sujet. Il faudra donc adapter votre discours.

Une fois validé, il vous servira de bouclier en cas de problème. Vous serez factuel, "en fonction de cette exigence et de cette contrainte voici les solutions techniques que je vous propose". Si celles-ci viennent à évoluer ou ne vous ont tout simplement pas été communiquées, vous ne pouvez pas être tenu responsable de quelque chose que vous ignorez. Boomerang boomerang ! Tout ce que tu dis ça revient vers toi. 🏄🏻‍♂️
Bon, il vous faut quand même jouer le jeu. Il vous faut faire ce travail d'investigation, vous n'allez pas vous en tirer comme ça.

Comme pour chaque sujet, il n'y a pas une seule façon de l'aborder, ceci reste ma vision et les grandes lignes de mes pensées basées sur mon expérience.
Il existe de nombreux livres, de nombreuses autres personnes qui parlent de ce sujet, à vous de prendre le meilleur de chacun.
Je vais vous expliquer (pour moi) de quoi doit être composé au minimum un DAT en 2025. Il peut être plus ou moins détaillé en fonction des exigences de la solution.

Personnellement, j'aime les choses simples et faciles à lire. Je privilégie un document principal pas très long et non ennuyeux, quitte à détailler dans une annexe ou un document dédié.
Fini les DAT de 150 pages que personne ne lit et qui mettent 6 mois à être écrits (et qui coûtent bien trop cher).
N'oubliez dans quel monde nous vivons. Nous demandons à des IA de nous écrire des romans, pour finir par demander à d'autres IA de résumer ce même roman. Autant écrire de suite quelque chose qu'un humain va pouvoir lire sans cramer la moitié de l'amazoni.

Cet article est décomposé en plusieurs chapitres avec des sujets macro, vous ne trouverez pas ici un guide complet. À vous de faire vos recherches et de l'adapter en fonction de votre contexte.

Bon allez, j'ai déjà trop parlé, les infos sont juste ici. 👇

Chapitres

Exigences / Contraintes

Vous pouvez avoir vos propres exigences et contraintes, mais en entreprise vous ne créez pas une infrastructure pour vous.
Elle est souvent commandée pour le business, ce sont eux qui doivent vous donner la plus part de ces informations. Pensez au service final que vous devez rendre.
N'oubliez pas au passage les différentes équipes comme la sécurité, le réseau, la gestion d'identité...etc. Elles peuvent avoir des contraintes plus ou moins complexes. Sans ça, l'approbation et l'intégration seront tout simplement impossibles.

Cela peut être des fixes / améliorations / nouveaux besoins métier / budget financier alloué pour l'hébergement de votre solution / disponibilité / scalabilité / sécurité au niveau du SI / contrainte de gouvernance (landing zone) ou organisationnelle.

Représentez tout ça dans un tableau avec des ID et faites-y appel dans le reste du document pour appuyer vos choix.

⚠️ N'oubliez pas, c'est le business/projet qui doit donner ces exigences ⚠️

PS : Il se peut qu'une exigence soit incompatible avec une contrainte donnée par une autre équipe. Si ce n'est pas surmontable d'aucune façon et que sans ça le projet ne peut pas fonctionner, ne perdez pas du temps à réaliser le reste de l'étude. La probabilité d'aller à l'implémentation est faible, connectez-vous sur Candy Crush et passez un bon moment. (Cet article n'est pas sponsorisé)

Analyse de l'existant

Avant de savoir où l'on va, il faut savoir d'où l'on vient. Il est possible de commencer sur un projet totalement vierge mais dans la plupart des cas, il y a toujours un POC, un ancien environnement, de la dev dans un coin, ou même le fameux PC data center présent sous un bureau.
Vous l'avez compris, l'objectif est de récupérer tous les schémas, inventaire, ressources, volumétrie, nombre d'utilisateurs, le coût actuel, quelle équipe gère le projet, les utilisateurs concernés, que vous pouvez trouver.

Propositions

Faites plusieurs propositions.
Elles doivent être en lien avec les exigences/contraintes mais aussi avec les bonnes pratiques de la techno.
Si l'éditeur est sérieux, il vous donnera toutes les informations nécessaires pour implémenter le/les service(s) avec les bonnes pratiques.
C'est le moment de faire appel à vos ID du chapitre "Exigences / Contraintes" 😉

N'oubliez pas qu'un schéma vaut 1000 mots.

Les solutions les plus simples sont souvent les plus maintenables. Montrer que vous avez les capacités intellectuelles de construire une machine à gaz alors que vous n'en avez pas besoin est juste de l'égo, et ça fait perdre du temps à tout le monde !

Interconnexion externe

À moins que votre solution soit totalement isolée du reste du monde, vous aurez besoin de vous interconnecter.
Je vous conseille de faire également un schéma.
N'oubliez aucun élément qui communique avec votre future infrastructure.
Vous pourrez également vous servir de ces éléments pour éventuellement démontrer que votre solution répond au besoin mais qu'un élément extérieur représente un risque.

Mise en œuvre / migration / évolution

Ce chapitre est composé de deux grosses parties.

Le plan de mise en œuvre/migration. Concrètement, comment allez-vous mettre en place cette solution. La question préférée de vos supérieurs : "Combien". Combien de temps il faut, avec combien de personnes, et enfin combien cela va me coûter. Si jamais on ne vous pose pas cette question, je vous offrirai une menthe à l'eau volontiers 🍹. Nous sommes en 2025, alors s'il vous plaît, incluez dans votre plan l'utilisation de l'infrastructure as code.
Une fois que vous l'avez mise en place (félicitations), il vous faudra le faire évoluer, en gros le setting et l'upgrade. Une seule solution, une pipeline CI/CD. Hors de question de faire une modification manuellement et sans vérification.

Pour ces deux piliers, vous avez une multitude de techniques, à vous de choisir ce qui vous convient le mieux.

Quelques petits exemples :

Blue green
Canary
Rolling-upgrade
A/B testing
Recreate deployment

Et pour le choix du pipeline, je pense que vous n'aurez pas trop de mal à trouver chaussure à votre pied.

MCO

MCO pour maintien en condition opérationnelle.
En fonction de l'infrastructure, il est probable que certains composants nécessitent d'être chouchoutés.
L'objectif est de déterminer quel composant nécessite une intervention.
Il est possible d'aller plus loin, en donnant la fréquence, le risque, l'obsolescence déjà annoncée.
Dans le cloud, beaucoup de ressources sont managées, mais n'oubliez pas que certaines d'entre elles ne le sont pas. Les mises à jour, hot fixes, montées de version sont possibles tout au long de la vie de votre infrastructure.
Hormis le fait que votre infrastructure ne fonctionnera tout simplement pas. Vous vous risquez à des failles de sécurité qui auront un effet tout aussi dévastateur sur votre réputation qu'une indisponibilité.

Supervision

Plusieurs éléments abordés dans cette partie.

Logs applicatifs
Logs infrastructure
Health check sur les services et/ou test end to end
CPU / RAM / Disque
Consommation avec des budgets et des alertes
CMDB

Nous devons savoir ce qu'il se passe. Référencez les composants critiques qui méritent une attention particulière. Dans tous les cas, rien n'est écrit dans le marbre. Vous allez faire évoluer la supervision en fonction de vos besoins.
Il est important de ne pas partir sans aucune visibilité. Sans ça, vous ne pourriez pas savoir si votre solution est fonctionnelle à 100% ou non. C'est quand même dommage d'avoir travaillé si dur pour échouer aussi rapidement.

Backup / PRA

Votre capacité à restaurer une partie ou en intégralité votre solution est primordiale.
Ne pensez pas que les problèmes n'arrivent qu'aux autres et que les backups sont secondaires.
Même les plus grandes sociétés tech ont eu leur nom dans les journaux.
La phrase "tester c'est douter" est très sympa devant la machine à café mais beaucoup moins à 3 heures du matin.

N'oubliez pas d'inclure des tests de restauration/déploiement. Ce n'est pas parce que votre Terraform a très bien fonctionné il y a 3 ans, qu'il sera aussi facile de le redéployer.

Concentrez-vous sur les composants state-full en priorité.

Pour des plans de reprise d'activité (PRA) évolués, il est tout à fait envisageable d'imaginer une solution capable d'adopter une stratégie multi-régionale voire même multicloud selon la criticité.
Pour aller plus loin, nous pouvons parler des RPO / RTO.
C'est un sujet complexe, cela peut faire l'objet d'un document dédié.

Bon maintenant que vous avez pris un bon petit coup de chaud, n'oubliez pas que certains projets ne sont pas critiques. Il est tout à fait entendable d'avoir un SLA très élevé si le business le permet.

Tout cela a un coût et il doit être étudié.

Analyse de risque / Sécurité

C'est un vaste sujet.
Première étape, posez-vous la question : Votre nouvelle solution représente-t-elle un risque pour le système informatique existant ?
Y aura-t-il des effets de bord ?
Si oui, comment allez-vous les gérer ?

L'analyse de risque doit également prendre en compte des limites potentielles au niveau de vos services, composants, connexions ou même providers. Que ce soit des soft ou des hard limits.

Vous devez apporter des réponses à vos risques.

Et enfin, il vous faut une stratégie de contrôle ou de pentest pour vous assurer que tout est en conformité.

FinOps

On va parler pognon ! Le prix de votre infrastructure va impacter directement sur les bénéfices de l'entreprise.
C'est comme ça. Ça coûtera toujours trop cher pour la direction et pour les actionnaires.

Il est important de récupérer le budget alloué pendant la phase de "Exigences / Contraintes" évoquée précédemment.

Pas de magie, vous allez devoir être en-dessous.
Présentez une budgétisation macroscopique avec une évolution dans le temps. Certains services transverses comme les logs et les backups peuvent coûter plus cher au fur et à mesure.
Le plus compliqué va être la budgétisation de la charge. Bonne chance... Je n'ai pas de solution miracle, cela sera du prévisionnel.
À vous de réaliser votre budget réel et de vous assurer que les objectifs financiers sont atteints.

Présentez donc un budget macroscopique ainsi que des solutions concrètes pour réduire les coûts.
Création automatique d'infrastructure de hors prod à la demande, scaling et sizing des ressources maîtrisées, shutdown de certains composants non critiques. Tout est bon à prendre.
Si possible, comparez avec la consommation existante.
Vous pouvez aussi aborder la facilité de refacturation en fonction du modèle économique adopté.

Pour appuyer l'importance du FinOps, sentez-vous libre d'évoquer que certaines entreprises ont dû mettre la clé sous la porte parce que leur coût d'infrastructure était trop élevé pour pouvoir se dégager du bénéfice.
Vous êtes tous dans la même équipe.

Au cours de mon expérience passée, j'ai pu voir des économies de plus de 30% seulement grâce à un peu de ménage et une bonne gouvernance. Ne vous inquiétez pas pour moi, je n'ai reçu 30% d'augmentation.
Mais peut-être que vous pourriez valoriser ce gain en l'utilisant pour de la R&D ou des chocolats pour Noël. 🤗

Recrutement / formation / structuration d'équipe

Cette partie est pour moi constamment oubliée ou minimisée.
Le changement n'est pas anodin. Vous allez trouver beaucoup de réfractaires à utiliser de nouvelles technologies ou méthodes.
R.I.P aux personnes qui n'ont pas voulu utiliser l'outil informatique il y a 30 ans et qui disaient qu'internet n'était qu'une mode... 🪦

Plus sérieusement, l'objectif, vous l'avez compris, est de n'oublier personne 😇. Si vous pensez by design à l'accompagnement au changement, vous éviterez énormément de friction.
N'oubliez pas que chaque personne en accord avec votre solution est un sponsor potentiel qui contribuera au bon déroulement de votre implémentation.

Les questions à vous poser :

Les équipes doivent-elles être formées ?
Faut-il embaucher de nouvelles personnes ?
Doit-on restructurer les équipes ?
Voir, doit-on faire une réduction d'effectifs car la nouvelle solution ne nécessite plus autant de personnes ?

Ne négligez pas ce chapitre, pensez aux autres, c'est aussi penser à vous !

Documentation

Pas de grande surprise, référencez ici tous les liens vers différents docs / blogs / REX / vidéos / blueprints utilisés pour réaliser ce document.

MAIS aussi, mettez en évidence comment vous allez référencer et documenter votre nouvelle super infra.
N'oubliez pas à quel point il est compliqué de reprendre un sujet sans aucune information.

Et si je suis tout seul, comment je fais ?!

Effectivement, j'ai orienté mon document plutôt pour des entreprises type TPE, PME, grand groupe 🥲.
Mais quand est-il de nos amis les solopreneurs ?
Et oui, je ne vous ai pas oubliés, futur vibs codeur ex-boulanger.
Votre route sera longue. Si j'ai un seul conseil à vous donner, utilisez ces nouveaux fabuleux outils comme porte d'entrée dans le joyeux monde de l'informatique.
Gardez en tête tout ce que vous avez pu lire ici, faites-vous un mini DAT pour ne pas oublier des étapes et surtout faites-vous accompagner par des professionnels qui ont de l'expérience le moment venu.
Les deux univers ne sont pas incompatibles 🫶, tout est encore une fois une question d'équilibre.
Tout le monde a de bonnes idées, mais la concrétisation est bien plus compliquée.

Conclusion

Rome ne s'est pas bâtie en un jour.
Écrire de jolies phrases dans un document n'est pas toujours simple, alors imaginez quand il s'agit de leur donner vie.
Implémenter tous les points de votre DAT est un objectif, avoir cette maturité d'infrastructure et la garder dans le temps n'est pas chose facile.
Vous allez devoir naviguer avec les cartes que vous avez en main et le DAT vous servira de guide☀️.