Ce que je fais vraiment, ce que je ne fais pas, et pourquoi c'est plus important que les mots-clés

Sur LinkedIn, un profil peut sembler décalé à ceux qui magasinent par mots-clés, mais sur le terrain, la vraie valeur se trouve souvent dans l'écart entre l'étiquette attendue et la capacité réelle à régler les problèmes.

Il se passe quelque chose d'assez révélateur sur LinkedIn.

Quelqu'un tape quelques mots-clés. "DevSecOps". "Architecte infonuagique". "Transformation plateforme". "Sécurité". Un petit cocktail de termes à la mode, bien tassé, sans trop lire plus loin. Puis cette personne tombe sur mon profil et réalise assez vite que je ne cadre pas parfaitement avec l'image toute faite qu'elle avait en tête.

Tant mieux.

Ce n'est pas un accident. Ce n'est pas non plus une coquetterie de profil. C'est volontaire.

Après des années à travailler dans de vrais contextes d'entreprise, avec des pipelines fragiles, des contrôles mal intégrés, des équipes fatiguées, des urgences qui reviennent et des comités qui découvrent les problèmes trop tard, j'ai appris une chose simple: un bon match de mots-clés, ce n'est pas la même chose qu'un bon match de problèmes.

Le premier aide les moteurs de recherche. Le second aide les organisations à respirer un peu mieux.

Je ne cherche pas à être tout pour tout le monde

Autant le dire clairement.

Je ne me présente pas comme une ressource générique qu'on peut déposer dans n'importe quel mandat pour produire de beaux artefacts PowerPoint et donner une impression de mouvement. Je ne fais pas dans le théâtre organisationnel. Je ne viens pas coller un vernis de sécurité sur un système de livraison instable pour que tout le monde se sente plus mature pendant deux semaines.

Et si le vrai objectif consiste à garder les mêmes mauvaises habitudes tout en changeant le vocabulaire, je ne suis probablement pas la bonne personne.

Ça peut sembler direct, mais les environnements de livraison le sont aussi. Les contraintes sont réelles. Les angles morts coûtent cher. Les compromis mal assumés finissent toujours par se présenter quelque part: dans les incidents, dans les audits, dans la dette opérationnelle, ou dans le moral des équipes.

Là où j'interviens vraiment

Mon travail se trouve au croisement de la livraison logicielle, la sécurité, la gouvernance, la résilience et les habitudes d'ingénierie.

C'est souvent là que les problèmes les plus coûteux se cachent.

Le pipeline semble automatisé, mais il casse dès qu'on le bouscule un peu. Les contrôles existent sur papier, mais personne ne leur fait confiance. L'Infrastructure as Code est présente, mais appliquée de manière inégale, sans vraie détection de dérive ni garde-fous partagés. Les équipes déploient vite ici, bloquent là, et compensent avec des exceptions parce que le système n'a jamais été conçu pour rendre la bonne chose facile à faire.

C'est précisément ce type de tension qui m'intéresse.

Je travaille autant sur les mécanismes que sur les comportements. Je veux savoir si votre CI/CD soutient réellement un changement sécuritaire, si vos règles sont explicites, versionnées et compréhensibles, si les secrets sont gérés proprement, si la chaîne d'approvisionnement logicielle est traitée avec sérieux, et si l'observabilité raconte la vérité au lieu de simplement générer du bruit [1][5].

Autrement dit, je ne regarde pas seulement les outils. Je regardece qu'ils permettent, ce qu'ils cachent, et ce qu'ils encouragent.

Pourquoi mon profil peut surprendre

Si quelqu'un s'attend à un spécialiste ultra étroit, rangé bien proprement dans une seule case, mon profil peut sembler un peu dérangeant.

Parce que je ne parle pas seulement d'un outil, d'une plateforme ou d'une pratique isolée. Je relie les éléments entre eux. Et ça, sur le terrain, ça compte énormément.

Les vrais problèmes de livraison ne se présentent pas comme des catégories LinkedIn. Ils se présentent comme des symptômes:

• des validations de sécurité qui arrivent trop tard
• des scanners que tout le monde ignore parce qu'ils crient sans discernement
• des déploiements qui demandent encore des contournements manuels
• des règles d'approbation mal adaptées au niveau de risque
• des changements d'infrastructure difficiles à retracer
• des preuves éparpillées quand vient le temps de démontrer la conformité
• des équipes qui se renvoient la balle parce que l'imputabilité est floue

Ce genre de situation ne se règle pas avec un meilleur slogan. Ça se règle avec une lecture systémique, une gouvernance praticable, et une intégration intelligente de la sécurité dans la façon de livrer [2][6].

Ce que je fais concrètement

J'aide les organisations à rendre leur livraison plus sécuritaire, plus gouvernable, plus résiliente et moins épuisante pour le monde.

Ça peut vouloir dire:

• cartographier le parcours du code, du commit jusqu'à la production
• identifier où les contrôles existent, où ils échouent, et où ils sont contournés
• renforcer les étapes build, test et déploiement avec des garde-fous utiles plutôt que décoratifs
• mieux encadrer l'Infrastructure as Code avec revue, traçabilité, parité d'environnements et détection de dérive
• introduire ou rationaliser des pratiques de Policy-as-Code pour rendre les règles visibles et cohérentes
• améliorer la gestion des dépendances, des secrets, des conteneurs et de la provenance des artefacts
• mettre en place des boucles de rétroaction observables autour des incidents, des exceptions, du délai de livraison, du retravail et des régressions

Quand on le fait bien, on commence à voir apparaître plus de cohérence, plus de traçabilité et une automatisation qui sert réellement la livraison, pas seulement la démonstration [1].

Je peux être dans la stratégie, oui. Mais si ça ne descend pas dans les pratiques concrètes, les workflows, les règles de merge, les approbations, les preuves et les habitudes quotidiennes, on reste dans l'intention. Et l'intention seule, en technologie, a une fâcheuse tendance à ne pas déployer grand-chose.

Ce que je ne fais pas

Je ne traite pas la sécurité comme un costume de conformité.

Je ne crois pas que la gouvernance devrait débarquer en fin de parcours comme une embuscade bureaucratique.

Je ne pense pas qu'ajouter de la friction aux développeurs soit une stratégie en soi.

Je ne confonds pas l'automatisation avec le jugement humain.

Je ne confonds pas non plus un tableau de bord avec une compréhension partagée de la réalité.

Et je ne crois pas qu'on bâtit une culture d'ingénierie saine sur des exceptions permanentes, des responsabilités floues et une frustration polie entre équipes.

On a déjà vu ce film-là.Il finit rarement avec une plateforme stable, un audit serein et des gens reposés.

Pourquoi cette différence peut être un avantage

Alors oui, quelqu'un peut arriver sur mon profil parce que quelques mots-clés correspondent à sa recherche, puis constater que je ne me présente pas dans le format interchangeable auquel il s'attendait.

Mais cette différence-là est peut-être justement l'intérêt.

Si vous cherchez une personne qui reste strictement dans un corridor très étroit, il existe probablement de meilleurs profils que le mien.

Mais si vous cherchez quelqu'un capable de relier les pratiques de livraison, les obligations de gouvernance, les points d'intégration sécurité, les réalités plateforme, les mécanismes CI/CD, l'IaC, la chaîne d'approvisionnement et les comportements humains sans perdre le fil, là, mon profil commence à faire pas mal plus de sens [4][5].

Le bénéfice, ce n'est pas d'être différent pour être différent.

Le bénéfice, c'est d'être utile exactement là où les déconnexions coûtent le plus cher.

Une dernière mise au point

Je n'essaie pas d'avoir l'air de tous les résultats de recherche. J'essaie d'être pertinent dans des environnements où la vitesse, la sécurité, la qualité, la gouvernance et la réalité humaine doivent cohabiter pour vrai.

Si mon profil vous semble un peu moins prévisible qu'attendu, ce n'est pas parce qu'il manque quelque chose. C'est parce qu'il reflète une pratique plus large, plus ancrée, et franchement plus proche de ce que les organisations vivent au quotidien.

Bref, avant de conclure qu'un profil ne cadre pas parfaitement avec le mot-clé qui vous a amené là, ça vaut parfois la peine de lire un peu plus loin. C'est souvent à cet endroit que commence la conversation utile.

Références
https://jpsoftworks.com/
https://jpsoftworks.com/blog
https://slsa.dev/
https://owasp.org/www-project-software-assurance-maturity-model/
https://www.nist.gov/cyberframework