Frederick Van Brabant explique que la dette architecturale ne se limite pas à la dette technique : elle s'étend bien au-delà du code et des décisions structurelles logicielles. En tant qu'architecte d'entreprise, il souligne que la dette architecturale concerne aussi les interactions entre applications, la gestion des données, les goulots d'étranglement, la maintenance, et le rôle futur des systèmes dans l'organisation. Il distingue trois couches principales de dette architecturale : application/infrastructure (intégration, redondance, dépendance aux fournisseurs), métier (propriété des processus, documentation obsolète, risques opérationnels) et stratégie (mauvaise définition des capacités, cadres incomplets, conséquences à long terme). Contrairement aux développeurs, les architectes d'entreprise ont la visibilité et les ressources pour identifier et prioriser ces dettes, en s'appuyant sur des tableaux de bord et des analyses pour convaincre les décideurs. L'article insiste sur l'importance de documenter, aligner les processus et éviter les hypothèses erronées, tout en choisissant ses batailles pour corriger les dettes les plus critiques, notamment dans les systèmes centraux plutôt que dans les projets d'innovation.

Dans ce billet, l’auteur souligne que les équipes de développement évoluent constamment avec les arrivées et les départs de membres, ce qui crée à chaque fois une nouvelle dynamique d’équipe. Ces changements entraînent des pertes de connaissances non documentées ou des décisions implicites, mais aussi l’apport de nouvelles perspectives. Pour atténuer les perturbations, il est crucial d’avoir une documentation claire, une vision partagée et des standards de développement bien définis (architecture, choix techniques, processus de revue de code, stratégie de tests, etc.). Ces éléments permettent de maintenir une cohérence et une direction commune, même lorsque la composition de l’équipe change. L’idéal serait d’automatiser cette documentation pour qu’elle reste toujours à jour et accessible, assurant ainsi la stabilité du projet sur le long terme.

L’article explique que les développeurs n’ont pas besoin d’être des designers pour créer des interfaces utilisateur efficaces. Cinq principes clés sont détaillés : la couleur (théorie, palettes, et règles comme 60-30-10), la typographie (choix des polices, interlignage, espacement des lettres), la hiérarchie visuelle (taille, poids, contraste, espace), le contraste (accessibilité, lisibilité), et l’alignement (ordre et équilibre). Ces concepts permettent de guider l’utilisateur, d’améliorer l’expérience et de rendre les interfaces plus professionnelles et accessibles, même sans expertise en design. L’article encourage à s’inspirer d’outils comme Coolors ou Fontpair et à pratiquer pour progresser.

Que se passerait-il si on tombait dans un trou noir ? L’article démystifie cette question en expliquant d’abord que le trou noir n’est pas un "aspirateur cosmique", mais un astre extrêmement dense, où la gravité est si intense qu’elle déforme l’espace-temps. Pour un observateur extérieur, une personne tombant vers un trou noir semblerait ralentir jusqu’à s’immobiliser à l’approche de l’horizon des événements, tandis que pour la personne elle-même, le temps s’écoulerait normalement jusqu’à la traversée de cet horizon. Une fois franchi, plus rien ne peut en ressortir, pas même la lumière. La relativité générale montre que le temps et l’espace sont relatifs : la personne en chute libre verrait l’univers extérieur s’accélérer, tandis que l’observateur lointain la verrait figée, puis disparaître. Les forces de marée étireraient ensuite la matière jusqu’à la "spaghettification". Enfin, la théorie actuelle ne décrit pas ce qui se passe au-delà de l’horizon, où les équations deviennent aberrantes.