AlpesCraft 2026 : bilan d’une édition sous le signe de l’audace

En coulisse 

La conférence est organisée par une équipe de 8 personnes réparties en commission autonome. Une commission est un petit groupe de personnes s’occupant d’une partie bien précise de la conférence. On y retrouve par exemple la commission billetterie, la commission communication pour tout ce qui touche aux communications sur les réseaux sociaux, la commission programme pour l’organisation des talks et des ateliers. Ce mode d’organisation nous permet de faire en sorte qu’un pan de la conférence puisse avancer et ne pas bloquer les autres parties.

Le budget d’une telle conférence est d’environ 27 000€ répartie entre la location du lieu, les repas, des frais de déplacement, d’hébergement et d’autres dépenses annexes. La conférence dépend entièrement de la vente de ses billets mais également du soutien des sponsors qui acceptent d’aider un tel événement. 

Enfin, à la différence des autres conférences techniques, le programme d’AlpesCraft n’est pas issu d’un CFP. A la place, nous sélectionnons les personnes et les sujets, et nous discutons avec chaque oratrice et chaque orateur pour comprendre leurs idées, échanger dessus, et voir comment elles s’intègrent à ce qu’on souhaite vous faire découvrir. 

C’est un exercice chronophage mais c’est ce qui nous permet de garantir que la conférence soit un véritable lieu d’échange, d’apprentissage et de connexion pour la communauté, et nous avons la conviction que cela commence dès la constitution du programme.   

Retour sur quelques conférences 

Git reset –hard - Adeline Morel

On nous apprend à construire, à innover, à ajouter des couches de fonctionnalités. Mais on nous parle rarement de l’art de savoir abandonner. Pourtant, combien de fois avons-nous perdu des heures, voire des jours, sur une piste sans issue, simplement parce que notre cerveau nous poussait à "sauver" ce qui était déjà perdu ? 

C’est là que les biais cognitifs entrent en jeu : 

• Le biais des coûts irrécupérables : "On a déjà trop investi pour tout jeter maintenant." 
• L’aversion à la perte : L’idée de "perdre" du travail, même inefficace, nous bloque psychologiquement. 
• Le biais de confirmation : On cherche (et trouve) des preuves que notre approche est la bonne… même quand elle ne l’est pas. 
• Le biais d’ancrage : Les premières idées d’un projet influencent toutes les suivantes, même si elles sont erronées. 

Résultat ? On s’obstine, on accumule du code médiocre, et on gaspille un temps précieux. Et si le vrai gaspillage, c’était de ne pas oser tout effacer ? 

Comme l’a souligné Adeline, issue d’une reconversion professionnelle, savoir reconnaître une impasse est une compétence à part entière. Le reset n’est pas un échec, mais un choix stratégique : celui de ne pas s’enfermer dans une mauvaise direction. 

Pour avancer sans crainte, il faut : 

• Travailler en petites unités (baby steps) : Moins on avance loin, plus il est facile d’accepter de reculer. 
• Faire des commits fréquents : Comme des checkpoints dans un jeu vidéo, ils permettent de revenir en arrière sans tout perdre. 
• Adopter des méthodes de travail : 
• Méthode Mikado : Isoler les dépendances pour faciliter les retours en arrière. 
• TCR (Test, Commit, Revert) : Une pratique qui force à valider chaque petit pas… ou à tout annuler si le test échoue. 

En conclusion, git reset-hard n’est pas une capitulation, mais une libération : celle qui permet de se détacher du superflu pour se concentrer sur l’essentiel. La meilleure ligne de code est celle qu’on n’a pas écrite. 

La sécurité n’est pas un mur, c’est un jeu de probabilités - Marine du Mesnil 

Et si la vraie question n’était pas "Suis-je sécurisé ?" mais "Suis-je plus sécurisé que mon voisin ?"  

On imagine souvent la sécurité comme une forteresse imprenable, protégée par des murs infranchissables. Pourtant, la réalité est bien différente : la sécurité, c’est avant tout un jeu de probabilités. Les attaquants ne vous ciblent pas toujours directement. Ils scannent, automatisent, et exploitent ce qui tombe sous leur radar. Et dans ce jeu, votre objectif n’est pas d’être invulnérable, mais simplement moins vulnérable que les autres.  

Contrairement aux idées reçues, les vulnérabilités critiques ne se nichent pas toujours dans des algorithmes complexes ou des systèmes exotiques. Elles sont souvent là, sous nos yeux :  

• Dans un commentaire de code (comme dans le cas de Cegedim).  
• Dans une configuration par défaut jamais modifiée.  
• Dans une ligne copiée depuis Internet… ou générée par votre IA préférée.  
• Dans la documentation officielle (même celle de Next.js a déjà hébergé des failles).  

En 2024, 24 millions de secrets ont fuité sur GitHub. Pire : un faux secret posté en ligne a été exploité en moins d’une minute. Et devinez quoi ? 70 % de ces secrets étaient encore valides deux ans après. Un rappel brutal que les attaquants automatisent tout, y compris la récupération de données sensibles (à l’image de l’exploitation massive de Log4j).  

L’intelligence artificielle a changé la donne, elle amplifie les failles. Elle génère plus de code, et donc plus de surfaces d’attaque. Elle s’entraîne sur des sites comme Stack Overflow, où des failles pullulent. Elle reproduit parfois les erreurs du code existant (etf oui, elle copiera aussi vos mauvaises habitudes). Elle diminue notre compréhension du code (une étude d’Anthropic l’a même prouvé). Elle aide les attaquants : des outils comme Slack ont déjà été détournés via du prompt injection pour accéder à des messages privés (source : PromptArmor).  

L'IA augmente également la surface d’attaque. Des groupes chinois ont utilisé Claude Code pour espionner des entreprises américaines et européennes. Pourtant, Claude 4.6 Sonnet a aussi permis de découvrir 14 vulnérabilités "high" en un temps record. 

L’IA est un couteau suisse : elle peut être utilisée pour attaquer… ou pour se défendre.  

À vous de choisir votre camp. La sécurité ne repose pas sur une seule solution, mais sur une stratégie en couches :  

• La défense en profondeur :  
• Zéro Trust : Ne faites confiance à rien par défaut.  
• Secrets éphémères : Utilisez des canary tokens (faux secrets pour piéger les attaquants).  
• Segmentation : Isolez vos environnements et vos données.  
• La détection et la réaction : Shift Left :  
• Détectez les failles le plus tôt possible (linters pour éviter les XSS, outils comme Renovate).  
• Plan de continuité d’activité (PCA) : Préparez-vous à l’attaque, pas seulement à la prévenir.  
• Postmortem : Analysez chaque incident pour en tirer des leçons. 

L’IA devient une alliée. On peut l’utiliser pour scanner son code et détecter des failles. Marine nous explique qu’elle a mis en place dans son équipe des agents spécialisés pour la revue de code selon le modèle des 3S : Speed pour la performance, Secure pour la sécurité et Stable pour la stabilité et la cohérence du code. 

TDD, BDD, ... SDD ? Leçons apprises du BDD pour ne pas refaire les mêmes erreurs avec l'IA - Rose Lutz 

Le SDD (Spec Driven Development) est-il vraiment la révolution annoncée ? 

Sur les réseaux sociaux et dans les blogs, on le présente comme "la transformation la plus significative depuis l’agilité", un game changer pour l’ingénierie logicielle assistée par l’IA. Enfin un outil pour produire des spécifications de qualité ? Peut-être. Mais attention : l’humanité écrit des règles et des lois depuis des millénaires, et pourtant, les jurisprudences ne cessent de se multiplier. Autrement dit, une bonne spécification ne suffit pas à elle seule. 

Le SDD propose une approche claire : fournir à l’IA des spécifications précises avant de générer du code, en s’appuyant sur des outils dédiés comme Speckit, Tessl ou SpecDD. Le workflow ? Exploration, planification, design, exigences, tâches. Mais gare aux idées reçues : 

Le SDD n’est pas l’héritier du TDD ou du BDD. Ce n’est pas une méthode, mais un procédé et surtout, il ne définit pas ce qu’est une bonne spécification. 

Contrairement au TDD ou au BDD, où la spécification est exécutable et liée au code, le SDD propose une spécification statique. Résultat : sans exécution automatique, la génération de code n’est plus pilotée par les tests. On perd alors l’assurance de non-régression, et la documentation, au lieu d’être vivante, devient un simple artefact produit par l’IA. Avec son non-déterminisme, l’IA nous peine à garantir que rien ne régresse. 

L’histoire se répète : une nouvelle méthodologie apparaît, elle fonctionne dans un contexte précis, puis se répand, se certifie, se banalise… jusqu’à ce que les équipes l’appliquent sans en comprendre les fondements. Avec le BDD, l’enjeu était le shared understanding, l’alignement entre métier et développement, grâce à des exemples concrets. Aujourd’hui, avec le SDD, on risque de tomber dans le même travers : confondre l’approche et les outils (comme on l’a fait avec Gherkin et le BDD). 

Le SDD n’est pas une révolution pour l’industrie logicielle, mais une réponse professionnelle au chaos de la génération IA non supervisée. Pour en tirer parti, il faut lui transmettre les bonnes pratiques du craft, celles qui ont fait leurs preuves. 

L’IA est puissante, mais elle manque cruellement de contexte. Chaque nouvelle session est une nouvelle IA, avec une mémoire limitée par les tokens. Alors, comment faire ? 

• Poser des repères de qualité : Définir des skills adaptées à chaque contexte de session. 
• Faire du handoff : Résumer une session et partager ce résumé dans la suivante, pour maintenir une forme de continuité. 
• Ne pas faire du SDD un dogme : Ce n’est qu’un procédé, pas une religion. Et surtout, ne confondez pas l’approche et les outils. 

(10) Bpifrance.io : Présentation | LinkedIn