L’article de Teddy Ferdinand souligne que l’intégration tardive de la cybersécurité dans un projet limite ses options à des mesures radicales, comme bloquer la mise en production ou imposer des corrections coûteuses, faute de pouvoir ajuster l’architecture ou les choix techniques en amont. L’auteur explique que cette approche brutale résulte souvent d’un manque de collaboration précoce, où les critères de sécurité ne sont pas définis dès le début, transformant une revue finale en révélateur de problèmes évitables.
Ferdinand illustre que les blocages en fin de projet sont rarement perçus comme des solutions, mais plutôt comme des échecs, car ils surviennent après que les engagements métiers, les budgets et les délais aient été figés. Il insiste sur l’importance d’intégrer la sécurité dès les phases clés, en amont, pour éviter des arbitrages douloureux et des tensions entre équipes projet, métier et management.
Enfin, l’auteur rappelle que la sécurité ne vise pas à freiner les projets, mais à les sécuriser de manière proactive, en clarifiant les règles, les responsabilités et les critères de validation avant que les choix ne deviennent irréversibles.
L’article de Teddy Ferdinand critique l’idée reçue selon laquelle la cybersécurité serait le principal frein aux projets, soulignant que le vrai problème réside plutôt dans le flou organisationnel. Les règles imprécises, les responsabilités mal définies et les processus opaques créent une dette organisationnelle, où chaque équipe interprète différemment les attentes, menant à des blocages tardifs. Par exemple, des critères vagues comme "les accès doivent être sécurisés" sans détails concrets (MFA, gestion des droits, etc.) génèrent des incompréhensions et des risques non anticipés.
L’auteur explique que la sécurité n’est souvent que le révélateur de ces dysfonctionnements, intervenant trop tard dans un projet déjà mal maîtrisé. Les équipes découvrent alors des lacunes critiques (architecture non documentée, données sensibles exposées) qui auraient dû être identifiées en amont. Le manque de clarté dans les processus de validation et l’absence de SLA (accords de niveau de service) sapent la confiance et ralentissent in fine l’ensemble des parties prenantes.
En conclusion, Ferdinand plaide pour des règles explicites, des responsabilités attribuées et des critères de validation transparents, afin d’éviter que la sécurité ne soit perçue comme un obstacle alors qu’elle devrait être un garde-fou intégré dès la conception des projets.
L’article explore l’application de la pensée systémique en architecture d’entreprise, en s’appuyant sur des exemples concrets comme l’impact des bâtiments sur les oiseaux ou l’ajout d’arbres en ville. L’auteur souligne la complexité des interactions dans les organisations, comparables à des Unknown Unknowns (inconnues inconnues), difficiles à anticiper. Il présente la Matrice de Rumsfeld (connus/connus, connus/inconnus, inconnus/connus, inconnus/inconnus) pour structurer la réflexion stratégique, et propose les diagrammes de boucles causales en post-mortem pour analyser les effets émergents. Une approche pragmatique pour naviguer dans l’incertitude des systèmes complexes.
Addy Osmani partage son workflow de codage avec les modèles de langage (LLM) pour 2026, soulignant l'importance de la planification et de la gestion des tâches. Il recommande de commencer par une spécification détaillée et un plan de projet clair, en collaborant avec l'IA pour définir les exigences et les étapes de mise en œuvre. Ensuite, il suggère de diviser le travail en petites tâches itératives, traitant chaque fonctionnalité ou correction une par une. Cette approche permet de maximiser l'efficacité de l'IA et de maintenir un contrôle humain sur le processus de développement.
L'auteur imagine comment a été décidé l'ajout d'écran de veille Oqee sur la Freebox... et c'est triste.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur détaille les outils qu'il utilise et ses méthodes - voici le résumé :
- Noter ses idées dans Google Keep
- Définir les objectifs de son projet : objectifs généraux et objectifs "temporels" (court, moyen et long terme)
- Demander des retours au bon moment, aux bonnes personnes (définir son audience)
- Apprécier le temps de développement (choix des technos, frameworks, etc.) - utilisation de la méthode Pomodoro. S'il ne se sent pas motivé, l'auteur tente pendant 10 min de coder... Souvent ça suffit, mais sinon il s'arrête.
- Moins on s'éparpulle, mieux c'est - utilisation de Kanban avec Trello, une seule tâche "en cours" à la fois - pas d'évaluation précise du temps mais un macro sizing
- Prendre des habitudes - méthode "ne pas briser la chaîne" pour s'assurer de consacrer un minimum de temps chaque jour.
- Ne pas se mettre de pression inutile
- Éviter le perfectionnisme en se donnant des limites
L'auteur donne de bons conseils pour gérer ses side projets
Tout est dans le titre
Moralité : "faites confiance à vos développeurs et développeuses."
Une réflexion intéressante sur la gestion de projet et la nécessité du découpage
Pour citer l'auteur "Alors au lieu de chercher à estimer le temps de développement de votre projet, avancez d'un pas à l'aide de [ces] 4 étapes..."
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur explique comment classer les fonctionnalités d'un projet et l'intérêt de ce type de classement.