Ou comment arrêter de confondre vitesse et direction
On construit de plus en plus vite. On déploie, on scale, on itère. Mais on se pose de moins en moins souvent la question essentielle : pourquoi ? Et surtout : pour qui ?
Ce texte n’est pas une critique gratuite de la tech. C’est un appel à retrouver du sens dans ce qu’on fait au quotidien. Parce qu’entre les buzzwords et les injonctions à la transformation, on a parfois oublié l’essentiel : construire des choses utiles, durables, humaines.
Voici quelques principes qui nous semblent justes. Pas des vérités absolues. Juste des repères pour celles et ceux qui en ont marre de courir dans le vide.
1. Complexe n’est pas synonyme de pertinent
On a fini par confondre performance technique et empilement de couches. Trop d’abstraction, trop d’outils imbriqués, trop de sophistication pour résoudre des problèmes qui n’en demandaient pas tant.
Simplifier, ce n’est pas régresser ou manquer d’ambition. C’est retrouver l’essentiel. C’est comprendre vraiment ce qu’on construit, et pour qui. La clarté demande plus d’efforts que la complication — mais elle dure plus longtemps.
Un exemple ? Combien de fois avez-vous vu un projet partir sur une architecture micro-services ultra-découplée… pour un MVP avec trois utilisateurs ? La complexité prématurée, c’est une dette qu’on paie cher. Très cher.
2. Tout migrer dans le cloud ? Non. Pas par principe.
La vraie question reste toujours la même : pourquoi ?
Pourquoi déporter des services qui tournent, qui sont stables, maîtrisés, compris par l’équipe ? Si c’est juste pour cocher une case « modernité » ou suivre une mode, si c’est pour payer trois fois plus cher et perdre progressivement la main sur ses propres données, alors autant rester lucide.
Le cloud est un outil formidable. Mais un outil répond à un besoin. Pas l’inverse. Avant de migrer quoi que ce soit, posez-vous la question : qu’est-ce qu’on gagne vraiment ? Et qu’est-ce qu’on perd ?
Parce que oui, on perd aussi quelque chose : contrôle, prévisibilité des coûts, autonomie technique. Ce n’est pas un jugement. C’est un arbitrage. Assumons-le.
3. Chaque ligne de code a un poids
Écrire du code propre, léger, maintenable : ce n’est pas du luxe, c’est de la responsabilité.
Ne pas multiplier les dépendances « par défaut », juste parce que c’est rapide ou confortable sur l’instant. Penser au développeur ou à la développeuse qui passera derrière dans six mois, un an, trois ans. Ou à soi-même, quand on aura tout oublié du contexte.
Le code, c’est du langage. Et comme tout langage, il peut clarifier ou obscurcir. On choisit.
Concrètement ? Avant d’ajouter un nouvel outil ou une nouvelle brique logicielle à votre projet, demandez-vous si vous en avez vraiment besoin. Avant de réutiliser une solution toute faite trouvée sur internet, prenez le temps de comprendre comment elle fonctionne et ce qu’elle fait réellement. Le temps que vous « gagnez » aujourd’hui en allant vite, quelqu’un devra le payer demain pour démêler, réparer ou comprendre ce qui a été fait. Souvent vous-même.
4. Le matériel a une seconde vie. Et une troisième.
Acheter neuf par réflexe, c’est souvent de la flemme déguisée en pragmatisme.
Un PC ou un serveur bien entretenu, correctement configuré, peut tenir des années. C’est moins de déchets électroniques qui finissent dans des décharges à l’autre bout du monde, moins de ressources extractives mobilisées pour rien. Et au passage, c’est aussi des économies réelles — pas symboliques. Vraiment.
Prolonger la durée de vie de ce qu’on possède déjà, c’est un geste technique autant qu’éthique. Ça demande un peu plus d’effort ? Oui. Mais ça en vaut la peine. Pour le budget, pour la planète, pour la cohérence de nos actes avec nos discours.
5. L’inclusion, ce n’est pas un slide PowerPoint
On parle beaucoup d’équipes mixtes, d’accessibilité numérique, de diversité générationnelle, de neurodiversité. Très bien. Alors faisons-le vraiment.
Cessons de chercher des clones de clones dans nos processus de recrutement. Arrêtons de valoriser uniquement un parcours type, une école, un profil miroir.
La diversité, ça ne se décrète pas dans une charte : ça se construit dans les pratiques quotidiennes, dans les postes qu’on ouvre, dans les personnes qu’on écoute. Dans les critères qu’on choisit de mettre en avant — ou de laisser tomber.
Et l’accessibilité ? Ce n’est pas une option à ajouter en phase 3 « si on a le temps ». C’est une contrainte de design dès le départ. Parce que rendre un service accessible, c’est tout simplement bien le concevoir.
6. L’impact, c’est aussi humain
On parle beaucoup — et c’est bien — d’empreinte carbone, de consommation énergétique, de cycles de vie matériel.
On parle beaucoup moins de stress chronique, de fatigue cognitive, de pression permanente sur les équipes. De réunions qui s’enchaînent sans respiration. De notifications qui ne s’arrêtent jamais. De deadlines qui se télescopent.
Si notre « transformation numérique » ou notre « agilité à l’échelle » finit par flinguer les gens qui la portent, alors elle est ratée. Point.
La soutenabilité, c’est autant une question d’environnement que de conditions de travail. On ne peut pas prétendre construire une tech responsable si on épuise celles et ceux qui la font tourner.
7. Moins peut être mieux
On n’a pas besoin de dix fonctionnalités approximatives. On a besoin de trois qui fonctionnent vraiment, qui respectent les usages réels, qui ne polluent ni l’interface ni l’esprit de ceux qui s’en servent.
La tech n’est pas là pour remplir des cahiers des charges ou justifier des budgets. Elle est là pour rendre service. Pour résoudre des problèmes concrets. Pour simplifier ce qui peut l’être. Pas pour ajouter du bruit.
Demandez-vous : si vous deviez supprimer la moitié des features de votre produit, lesquelles garderiez-vous ? Celles qui restent, ce sont probablement les seules qui comptent vraiment. Le reste, c’est souvent de l’ornement.
8. Ce n’est pas un manifeste pour briller
Ce texte n’est pas une posture, ni un exercice de style pour se donner bonne conscience.
Juste un rappel : faire moins mais mieux, ralentir pour mieux viser, refuser certaines courses en avant, ce n’est pas être en retard ou passéiste. C’est refuser de foncer droit dans le mur en klaxonnant, persuadés qu’on innove parce qu’on va vite.
Innover, ce n’est pas toujours ajouter. Parfois, c’est retirer. Parfois, c’est juste faire ce qu’on fait déjà, mais en mieux. En plus propre. En plus juste.
Pour conclure
À celles et ceux qui bossent dans la tech, côté code ou côté décision :
On peut encore faire autrement. On peut encore choisir la cohérence plutôt que l’accumulation. Mais pas en recopiant les modèles d’hier. Et surtout, pas en se racontant des histoires pour se rassurer.
On sait ce qu’on fait. Ou on devrait. Alors faisons-le bien.
Pas pour être exemplaires. Juste pour être cohérents. Parce qu’au fond, c’est peut-être ça, une tech qui a du sens : une tech qu’on peut encore regarder en face dans dix ans.
Corinne Meynier est une personne passionnée par l’entrepreneuriat et la technologie. Elle a co-fondé Kabia en 2005, une entreprise proposant des services à haute valeur ajoutée axés sur les réseaux, la sécurité, l’hébergement internet à très haute disponibilité, le Cloud computing régional PACA et des solutions de mise en réseau et sécurité pour systèmes d’informations.
Elle prête sa voix au podcast Kabia
En plus de son rôle de co-fondatrice chez Kabia, Corinne Meynier est également engagée dans différentes organisations. Elle est membre du conseil d’administration d’EuroCloud depuis novembre 2022, une organisation qui promeut l’adoption du Cloud computing en Europe.
Corinne Meynier partage ses connaissances et son expérience à travers son podcast, qui a pour objectif de donner des clés simples pour comprendre le monde numérique que nous utilisons chaque jour. Elle est une entrepreneuse passionnée qui croit en l’importance de l’humain au centre de la technologie.