Utiliser l’IA dans le développement : Mon expérience avec les outils de spec

Depuis la fin de l’année dernière (octobre‑novembre 2025), j’ai remarqué une vraie évolution dans la manière dont les développeurs partagent leurs expériences autour de l’IA sur Twitter, Reddit.

Il y a bien sûr le videcoding, mais de nouveaux outils proposent un workflow plus structuré : on définit d’abord un plan, puis on laisse l’IA l’implémenter.

Dans cet article, je vous raconte comment j’ai testé plusieurs de ces solutions, pourquoi j’ai finalement choisi openspec, et quels bénéfices cela apporte au quotidien.

Le mode plan

Certains outils/ID ont introduit une étape de planification :

On peut alors discuter avec le modèle sur la feature à implémenter ou discuter de l’architecture sans modifier du code.

Pour ma part, j’utilise uniquement opencode, mais je suppose que le fonctionnement des autres outils est très similaire.

Avec le plan qu’on génère, on peut ensuite basculer en mode Build et faire l’implémentation.

Ça permet d’affiner assez facilement ce qu’on veut implémenter en choisissant le pattern, peut-être des bibliothèques à ajouter, modifier etc.

Cependant, dans mon cas, j’aimerais pouvoir garder ce plan d’une session à l’autre et ne pas avoir à refaire cette étape de brainstorming pour créer le plan.

Il y a alors encore d’autres outils qui viennent s’ajouter en parallèle comme beads, openspec, ou SpecKit (et encore bien d’autres).

L’idée de ces outils est, dans bien des cas, générer des PRD et de le garder en local dans le projet (possibilité de les versionner si on le souhaite).

Ça apporte de la structure aux documents générés et permet de garder en mémoire là où les tâches à faire.

L’utilisation d’openspec est assez simple, la doc l’explique bien :

Avec opencode, ça ajoute 3 commandes :

En créant une spec, le modèle va suivre un template particulier qui sera validé par la CLI d’openspec.

flowchart TD
    A[Définir la tâche] --> B[Le modèle propose un plan]
    B --> C[Révision collaborative]
    C --> D[Implémentation]

Mon choix : openspec (et les alternatives)

Pourquoi openspec ?

Autres solutions

Avantages concrets observés

  1. Vue d’ensemble claire – Le fichier feature.md résume la fonctionnalité, ce qui facilite la communication avec les co‑développeurs.
  2. Gestion des tâches – La checklist (tasks.md) permet de suivre le progrès et de cocher les items réalisés, bien que parfois le modèle ne mette pas à jour lui-même le fichier et il faut lui rappeler dans le prompt suivant de mettre à jour le tasks.md
  3. Scénarios de tests – specs.md décrit les comportements attendus (ex. : “Quand je fais A, j’attends B”).
  4. Reprise de session – On peut reprendre une spec depuis une autre session très facilement, il suffit de refaire un /openspec-apply some-spec et le modèle va la retrouver et savoir quelles sont les tâches restantes.

Un workflow type avec openspec

flowchart TD
    A[Définir la feature] --> B[openspec génère les .md]
    B --> C{Révision humaine}
    C -->|OK| D[Envoyer le plan à l'IA - implémentation]
    C -->|Modif| B
    D --> E[IA implémente le code]
    E --> F[Met à jour tasks.md et specs.md]
    F --> G[Commit et merge]
  1. Définir la feature (texte libre).
  2. openspec crée les fichiers Markdown.
  3. Révision : on ajuste le plan ou les scénarios.
  4. Envoi à l’IA : on lance l’implémentation.
  5. Mise à jour : les fichiers de suivi sont automatiquement rafraîchis.

Comment je l’utilise au travail

Contexte professionnel

Workflow

J’ai créé deux commandes pour opencode pour interagir avec openspec et Linear depuis opencode.

Une commande pour créer une issue depuis OC dans Linear.

<!-- create-issue.md -->
---
description: Create a new Linear issue using Linear MCP
---
The user wants to create a new Linear issue. Parse the request and create the issue using the Linear MCP tools.

<UserRequest>
  $ARGUMENTS
</UserRequest>

**Steps**
1. Parse the user's request to extract:
   - Issue title: The main subject of the issue (usually the first sentence or clause)
   - Issue description: The detailed description of what needs to be done
   - Project (optional): The project name or ID to associate the issue with
   - Status (optional): The issue state (e.g., "todo", "in progress", "done")
   - Labels (optional): Array of label names to add to the issue

2. If a project was specified, use `linear_list_projects` to find the matching project:
   - Search for projects using the project name from the user's request
   - Find the project that matches the name (case-insensitive partial match is ok)
   - Extract the project ID from the result

3. Use the `linear_create_issue` tool via MCP to create the issue:
   - Set `title` to a concise, descriptive title
   - Set `description` to the full details provided by the user
   - Set `project` to the project ID found in step 2 (if a project was specified)
   - Set `state` if a status was specified (use the status name directly)
   - Set `labels` as an array if labels were specified

4. After creation, if any of these optional fields were not set during creation:
   - Use `linear_update_issue` to add the missing fields:
     - If no project was set, update with the project ID from step 2
     - If no status was set, update with the status
     - If no labels were set, update with the labels array

5. Return a confirmation message with the issue ID and link.

Et une autre pour créer une spec avec openspec depuis un ticket Linear.

<!-- create-spec-from-linear.md -->
---
description: Create a new OpenSpec from a Linear issue by checking out a branch, updating issue status, and generating the spec document
---
Get the Linear issue with ID `$ARGUMENTS` and create an OpenSpec spec from it. Steps:
1. Use `linear_get_issue` to get the issue details (including branch name from `branchName` field)
2. Check that you're on `dev` branch with `git rev-parse --abbrev-ref HEAD`
3. Check git status with `git status --porcelain -u no` and ensure there are no modified/staged files
4. If on `dev` and clean, create new branch with `git checkout -b <branchName from issue>`
5. Update the Linear issue status to "In Progress" using `linear_update_issue`
6. Run the `@.opencode/command/openspec-proposal.md` command with the issue title and description as the user request to create the spec

Avec ces commandes, un workflow que j’explore est d’être sur Linear et de regarder des issues à traiter, de prendre l’ID correspondant et depuis OC lancer /create-spec-from-linear ISSUE-123.

À partir de là, le modèle devrait utiliser le MCP Linear pour récupérer l’issue, changer de branche si possible, mettre à jour le statut du ticket puis lancer la commande openspec-proposal avec le corps de l’issue.

Enfin, on retourne sur le workflow openspec <-> opencode dans lequel on itère avec le modèle si la spécification générée n’est pas encore valide.

Une fois que ça semble bon, on peut la valider et lancer le modèle sur l’implémentation.

/openspec-apply my-spec-from-a-linear-issue