Arda Akgür
Ce texte n'explique pas comment construire des systèmes parfaits. Je ne crois d'ailleurs pas qu'ils existent.
Ce sont des principes acquis au fil des années en construisant des systèmes, en écrivant du code, en enseignant, et en regardant des systèmes en production se briser.
Pour moi, l'ingénierie système, c'est d'abord résoudre un problème, ensuite choisir une technologie.
1. La chose la plus importante dans un système, c'est la stabilité
Quelle que soit la logique fondamentale avec laquelle tu as construit un système, ne réécris pas sans cesse cette logique une fois qu'il tourne.
Les paramètres peuvent changer. On peut faire de petites améliorations. On corrige les bugs. Mais si tu commences à changer les règles centrales en plein chemin, tu n'auras bientôt plus ni le design d'origine ni le nouveau.
Quand un changement majeur est vraiment nécessaire, le bon geste n'est parfois pas de forcer le système actuel — c'est de démarrer une nouvelle version.
Ne change pas les règles du jeu au milieu du jeu.
2. Construis le système le plus simple qui marche
Ne passe pas le premier jour à concevoir pour des millions d'utilisateurs, l'échelle à cinq ans, et des problèmes qui n'existent pas encore.
Ce n'est souvent pas de l'ingénierie. C'est de l'architecture YouTube.
Construis le système compréhensible qui résout le problème d'aujourd'hui le plus vite possible et qui fonctionne vraiment.
Si un jour tu as un vrai problème de scale, c'est un bon problème. Cela veut dire que le système a vécu assez longtemps pour y arriver.
Quand le V2 est nécessaire, tu peux le construire autrement.
3. Tiens-toi loin du statu quo
Que tout le monde utilise une technologie ou une architecture ne signifie pas que c'est juste pour ton problème.
« L'industry standard le dit » n'est pas à lui seul une justification technique.
Définis d'abord le problème. Puis regarde ce qui le résout le mieux.
Si la réponse est ce que tout le monde utilise, utilise-le. Sinon, n'aie pas peur de faire autrement.
Sois loyal au problème, pas aux outils.
4. Ne prends pas de décisions importantes en ayant faim ou en étant épuisé
L'outil le plus important d'un architecte n'est pas l'ordinateur. C'est l'esprit.
La faim et une fatigue sérieuse peuvent détruire la qualité des décisions. Une solution que tu rejetterais normalement peut soudain paraître « assez bonne ». Tu peux prendre des risques inutiles, t'énerver facilement, ou accepter une mauvaise décision juste pour finir.
Parfois cet état intoxique même. Tu te crois encore capable de décider — le jugement s'est déjà effondré.
À ces moments-là, tu peux faire du travail de routine : écrire du code, lancer des tests, inspecter des logs. Mais ne prends pas de décisions d'architecture coûteuses si tu peux l'éviter.
Si la décision peut attendre le matin et que tu es vidé, laisse-la attendre le matin.
La faim et la fatigue sont tes ennemies.
Avant de concevoir le système, l'architecte lui-même doit être opérationnel.
5. Si le code change, la documentation doit changer
À chaque mise à jour de code significative, mets aussi à jour la documentation.
Ne traite pas la documentation comme une tâche séparée pour après. Code et documentation sont les deux moitiés du même changement.
Les outils d'IA modernes rendent cela bien plus facile. Après chaque changement important, fais examiner le changement et le code associé par l'IA. Génère un Markdown qui décrit l'état actuel du système, ou mets à jour l'existant.
Garde la documentation dans le dépôt en `.md` autant que possible. Markdown est simple, se suit bien en version control, et s'affiche proprement sur GitHub.
Si un changement backend touche le frontend, partage le Markdown pertinent avec l'équipe frontend.
Un développeur frontend devrait comprendre le fonctionnement d'un endpoint, la forme request/response, le comportement changé et les pièges — sans devoir d'abord fouiller le code.
Le même principe vaut entre équipes et services.
L'IA accélère la documentation. La responsabilité de l'exactitude reste à l'ingénieur qui a fait le changement. N'accepte pas des docs écrits par l'IA sans les vérifier.
Si le code a été mis à jour et pas la documentation, le travail n'est pas terminé.
La documentation est la mémoire du système.
6. Vois d'abord le système terminé dans ta tête
Avant d'écrire du code, tu devrais pouvoir voir le système terminé dans ton esprit.
Si tu ne peux pas, prends un crayon et du papier et dessine.
Ce n'est pas obligé d'être un diagramme ER. Ni de l'UML. Ni le standard de qui que ce soit.
Dessine des cases. Des flèches. Écris des notes à côté. Dessine comme ça te parle.
La beauté n'est pas le point. Pouvoir voir tout le système, oui.
Si tu essaies de découvrir un système que tu ne vois pas en codant, tu commences à concevoir et à implémenter en même temps.
Vois d'abord. Construis ensuite.
7. N'oublie pas pour qui est le système
Ne méprise pas les idées des managers non techniques et des utilisateurs.
Parfois une idée qui paraît techniquement bizarre regarde le problème sous un angle que tu n'as jamais considéré.
Leur rôle n'est pas de penser comme toi.
Ton rôle est de comprendre ce qu'ils veulent et, si possible, d'en faire un système qui marche.
Écoute leurs rêves et essaie de les réaliser. Parfois le résultat te surprendra vraiment.
Construis le système pour ceux qui l'utiliseront — pas pour toi.
8. L'architecte ne doit pas perdre le contrôle
Tout système sérieux a besoin de mécanismes fail-safe.
Tu dois pouvoir arrêter le système avec une seule variable d'environnement si besoin. Aie un endpoint de gestion contrôlé si nécessaire. Prévois des voies pour désactiver des pièces critiques.
Ce ne doivent pas être des portes dérobées secrètes qui percent la sécurité. Elles doivent être autorisées, sécurisées, et de préférence journalisées.
Aussi autonome que soit le système, l'architecte ne doit jamais devenir spectateur de son propre système.
Le contrôle final reste à l'architecte.
9. Suspecte d'abord ta propre erreur
Quand le système ralentit, ne blâme pas immédiatement le hardware.
Il y a peut-être un deadlock que tu ne vois pas. Peut-être une mauvaise query. Peut-être un appel réseau inutile. Peut-être une erreur d'architecture qui verrouille le système.
Oui — le hardware peut vraiment être insuffisant.
Mais mesure d'abord.
Un ingénieur doit pouvoir accepter qu'il peut avoir tort. Il n'y a aucune honte à cela.
Celui qui ne peut pas admettre s'être trompé ne peut pas non plus corriger son erreur.
10. Forme des étudiants
Ne laisse pas le système vivre seulement dans ta tête.
Enseigne le système à tes étudiants.
Si tu n'es pas là demain, le système doit pouvoir continuer. Qu'un autre puisse le comprendre et l'améliorer ne réduit pas ton autorité. Cela prouve que tu es un bon architecte.
Un système que seule une personne comprend n'est pas fort. Il est fragile.
Transmets la connaissance.
11. Travaille avec une petite équipe alignée
Ne sois pas un architecte solitaire. Ne construis pas non plus une équipe inutilement grande.
Travaille avec des gens ouverts à apprendre, qui écoutent, posent des questions, et n'ont pas perdu l'esprit d'étudiant.
La critique a de la valeur. Un junior peut voir le bug que tu as manqué. Écoute-le.
Mais ceux qui font de l'opposition constante un style de travail sont dangereux en construction de systèmes. Relitiger chaque décision sans fin force l'architecte à changer de direction et finit par détruire la stabilité.
Débat jusqu'à ce que la décision soit prise.
Une fois prise, exécute en équipe.
Tu n'es pas obligé de travailler longtemps avec quelqu'un qui bloque l'avancée par une opposition permanente.
12. Sois créatif, mais reste simple
Un ingénieur expérimenté devant un bon système devrait pouvoir dire « waouh ».
Et un bon junior entrant dans ce même système devrait comprendre à peu près ce qui se passe en environ une semaine.
Ces deux choses ne s'opposent pas.
La vraie maîtrise n'est pas d'utiliser cent services ni d'inventer des abstractions que personne ne comprend.
C'est résoudre un problème complexe avec un système étonnamment simple.
La complexité n'est pas un art.
13. Ne fourre pas chaque nouveauté dans l'ancien système
Quand une nouvelle idée arrive, ton premier réflexe ne devrait pas être de la fixer sur le système actuel.
Parfois il faut un nouveau service. Parfois une nouvelle application. Parfois vraiment un V2.
Si tu essaies d'étendre l'ancien système pour toujours, tu piles finalement des années de décisions et d'exceptions sur le système simple du départ.
Parfois repartir de zéro est moins cher, plus propre et plus juste.
Le changement ne signifie pas toujours agrandir le système actuel.
14. Utilise l'intelligence artificielle comme un outil
L'IA peut vraiment renforcer un système.
Les moteurs de reasoning modernes en particulier sont puissants à la construction et au runtime.
Ils peuvent relire du code, trouver des edge cases, soutenir des décisions, comprendre le langage naturel, et résoudre des problèmes ambigus où les algorithmes classiques peinent.
Mais ne déverse pas tout sur l'IA.
Si une solution déterministe simple suffit, utilise-la. Si le reasoning apporte vraiment de la valeur, utilise l'IA. S'ils marchent mieux ensemble, construis un hybride.
Donne du travail à l'IA. Ne lui donne pas l'autorité sur le système.
15. N'attends pas de miracles de l'IA
L'IA n'est intelligente que comme la personne qui l'utilise.
Si tu décris mal le problème, même un modèle très fort peut produire la mauvaise solution très vite.
Il faut savoir ce que tu veux. Comprendre assez le problème pour évaluer la réponse. Remarquer quand elle a tort.
L'IA n'a pas à être l'ingénieur à ta place.
Bien utilisée, elle étend ta capacité d'ingénierie.
N'attends pas de miracles.
16. L'habitude tire, et la merde sente
It is what it is.
Ne cherche pas un sens profond dans tout.
Parfois un bug n'est qu'un bug. Le mauvais code est du mauvais code. Une idée qui ne marche pas ne marche pas. Une mauvaise décision est une mauvaise décision.
Si une explication simple suffit, n'orne pas le problème de théories inutiles.
Regarde d'abord la réalité devant toi.
17. N'aie pas peur d'imiter le maître
En tant qu'étudiant, tu n'as pas à tout inventer.
Quand j'étais étudiant, j'ai réécrit de zéro des structures comme ArrayList pour apprendre. Le but n'était pas d'inventer une nouvelle structure de données.
Le but était de faire moi-même ce que faisaient les maîtres, comprendre comment ça marche, comparer avec ma solution, et grandir.
Apprendre par imitation n'est pas du plagiat.
Atteins d'abord le niveau où tu peux faire ce que le maître a fait. Essaie de comprendre pourquoi. Puis questionne. Puis développe ta méthode.
Rejeter ce que tu ne comprends pas juste pour être différent n'est pas de la créativité.
Apprends d'abord. Casse ensuite.
Mot de la fin
La bonne ingénierie système n'est pas l'art d'utiliser le plus de technologie possible.
C'est comprendre le problème, voir la solution dans sa tête, construire aussi simplement que possible, protéger la stabilité de ce qui marche, et pouvoir admettre sa propre erreur au besoin.
Un bon architecte connaît d'abord l'état de son esprit. Refuser les grandes décisions en ayant faim, en étant épuisé, ou incapable de penser clairement fait aussi partie de l'ingénierie.
Il protège la mémoire du système autant que le code. Il documente ce qu'il change et partage cette connaissance avec ceux qui continueront à construire le système.
Il contrôle son système — il ne l'adore pas.
Il mène son équipe — il ne fait pas taire ses étudiants.
Il utilise l'intelligence artificielle — il ne lui sous-traite pas la pensée.
Il apprend du passé — il ne se rend pas au statu quo.
Et le plus important : si le système marche, il essaie de comprendre pourquoi ; s'il ne marche pas, pourquoi.
Tout le reste est un outil.
Arda Akgür
Principes systèmes ARC
v0.1 Final